Stateless datastore-independent transactions

ABSTRACT

At a client-side component of a storage group, a read descriptor generated in response to a read request directed to a first data store is received. The read descriptor includes a state transition indicator corresponding to a write that has been applied at the first data store. A write descriptor indicative of a write that depends on a result of the read request is generated at the client-side component. The read descriptor and the write descriptor are included in a commit request for a candidate transaction at the client-side component, and transmitted to a transaction manager.

BACKGROUND

In recent years, more and more computing applications are beingimplemented in distributed environments. A given distributed applicationmay, for example, utilize numerous physical and/or virtualized serversspread among several data centers of a provider network, and may servecustomers in many different countries. As the number of servers involvedin a given application increases, and/or as the complexity of theapplication's network increases, failure events of various types (suchas the apparent or real failures of processes or servers, substantialdelays in network message latency, or loss of connectivity between pairsof servers) are inevitably encountered at higher rates. The designers ofthe distributed applications are therefore faced with the problem ofattempting to maintain high levels of application performance (e.g.,high throughputs and low response times for application requests) whileconcurrently responding to changes in the application configurationstate.

Some traditional techniques for managing state information may involvelocking the state information to implement application state changes ina consistent manner. Unfortunately, the locking mechanisms used forapplication state and/or data can themselves often become performancebottlenecks as the application increases in size and complexity. Othertechniques may avoid locking, but may have to pause normal operations topropagate changed state information among the application's components.Such “stop-the-world” periods may be problematic, however, especiallyfor latency-sensitive applications that are used for mission-criticalworkloads by hundreds or thousands of customers spread in different timezones across the world.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates an example system environment in which a dynamic DAG(directed acyclic graph) of replication nodes is established formanaging application state changes, according to at least someembodiments.

FIG. 2a-2h collectively illustrate an example sequence of operationsthat may be performed at a replication DAG in response to a detectionthat one of the nodes of the DAG may have failed, according to at leastsome embodiments.

FIG. 3 illustrates example components of application state records andDAG configuration-delta messages that may be generated at a dynamicreplication DAG according to at least some embodiments.

FIG. 4 illustrates an example replication DAG whose member nodes aredistributed across a plurality of availability containers of a providernetwork, according to at least some embodiments.

FIG. 5 illustrates an example configuration in which nodes of aplurality of replication DAGs may be implemented at a single host in amulti-tenant fashion, according to at least some embodiments.

FIG. 6 is a flow diagram illustrating aspects of operations that may beperformed at an acceptor node of a replication DAG in response toreceiving a state transition request, according to at least someembodiments.

FIG. 7 is a flow diagram illustrating aspects of operations that may beperformed at an intermediate node of a replication DAG in response toreceiving an approved state transition message, according to at leastsome embodiments.

FIG. 8 is a flow diagram illustrating aspects of operations that may beperformed at a committer node of a replication DAG in response toreceiving an approved state transition message, according to at leastsome embodiments.

FIG. 9 is a flow diagram illustrating aspects of operations that may beperformed at a configuration manager of a replication DAG, according toat least some embodiments.

FIG. 10 is a flow diagram illustrating aspects of operations that may beperformed at a member node of a replication DAG in response to receivinga configuration-delta message from a configuration manager, according toat least some embodiments.

FIG. 11a-11h collectively illustrate an example sequence of operationsthat may be performed at a replication DAG during a coordinatedsuspension procedure, according to at least some embodiments.

FIG. 12 is a flow diagram illustrating aspects of operations that may beperformed at a committer node of a state replication group such as areplication DAG during a coordinated suspension procedure, according toat least some embodiments.

FIG. 13 is a flow diagram illustrating aspects of operations that may beperformed at a non-committer node of a state replication group such as areplication DAG during a coordinated suspension procedure, according toat least some embodiments.

FIG. 14 is a flow diagram illustrating aspects of operations that may beperformed at a configuration manager of a state replication group suchas a replication DAG during a coordinated suspension procedure,according to at least some embodiments.

FIG. 15 illustrates an example system environment comprising apersistent change log supporting transactions that may include writes toa plurality of data stores, according to at least some embodiments.

FIG. 16 illustrates an example implementation of a persistent change logusing a replication DAG, according to at least some embodiments.

FIG. 17 illustrates example component elements of a transaction requestdescriptor that may be submitted by a client of a logging service,according to at least some embodiments.

FIG. 18 illustrates an example of read-write conflict detection at alog-based transaction manager, according to at least some embodiments.

FIG. 19 is a flow diagram illustrating aspects of control-planeoperations that may be performed at a logging service, according to atleast some embodiments.

FIG. 20 is a flow diagram illustrating aspects of operations that may beperformed at a logging service in response to a transaction requestreceived from a client, according to at least some embodiments.

FIG. 21 illustrates examples of transaction request descriptors that maybe used to achieve respective special-case consistency objectives,according to at least some embodiments.

FIG. 22 illustrates an example of enforcing a de-duplication constraintassociated with a transaction request received at a log-basedtransaction manager, according to at least some embodiments.

FIG. 23 illustrates an example of enforcing a sequencing constraintassociated with a transaction request received at a log-basedtransaction manager, according to at least some embodiments.

FIG. 24 illustrates an example of a transaction request descriptorcomprising multiple logical constraint descriptors, according to atleast some embodiments.

FIG. 25 is a flow diagram illustrating aspects of operations that may beperformed at a logging service in response to a transaction request thatindicates one or more logical constraints, according to at least someembodiments.

FIG. 26 illustrates an example system environment in which respectivepricing policies may be implemented for respective log-coordinatedstorage groups, according to at least some embodiments.

FIG. 27 illustrates examples of single-data-store and cross-data-storewrite operations, according to at least some embodiments.

FIG. 28 illustrates examples of factors that may be considered whendetermining pricing policies for log-coordinated storage groups,according to at least some embodiments.

FIG. 29 illustrates an example web-based interface that may be used toindicate pricing policy options to a user of a service implementinglog-coordinated storage groups, according to at least some embodiments.

FIG. 30 is a flow diagram illustrating aspects of operations that may beperformed to determine billing amounts at a service supportinglog-coordinated storage groups, according to at least some embodiments.

FIG. 31 illustrates an example sequence of events at a storage system inwhich the use of read-location-based conflict detection for transactionacceptance may lead to data inconsistency, according to at least someembodiments.

FIG. 32 illustrates a system environment in which a read descriptorprovided in response to a read request comprises a read repeatabilityverification metadata (RRVM) component, according to at least someembodiments.

FIG. 33 illustrates example constituent components of read descriptors,according to at least some embodiments.

FIG. 34 illustrates example transformations that may be applied to readdescriptors before the read descriptors are provided to client-sidecomponents of a storage system, according to at least some embodiments.

FIG. 35 illustrates an example sequence of events that may lead to ageneration of a candidate transaction commit request at a client-sidecomponent of a storage system, according to at least some embodiments.

FIG. 36 illustrates an example transaction manager that stores writedescriptors and read descriptors in respective logs, according to atleast some embodiments.

FIG. 37 is a flow diagram illustrating aspects of operations that may beperformed at a storage system in which read descriptors are provided inresponse to read requests, according to at least some embodiments.

FIG. 38 is a flow diagram illustrating aspects of operations that may beperformed at a storage system in candidate transaction requests aregenerated at a client-side component, according to at least someembodiments.

FIG. 39 is a block diagram illustrating an example computing device thatmay be used in at least some embodiments.

While embodiments are described herein by way of example for severalembodiments and illustrative drawings, those skilled in the art willrecognize that embodiments are not limited to the embodiments ordrawings described. It should be understood, that the drawings anddetailed description thereto are not intended to limit embodiments tothe particular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope as defined by the appended claims. The headings usedherein are for organizational purposes only and are not meant to be usedto limit the scope of the description or the claims. As used throughoutthis application, the word “may” is used in a permissive sense (i.e.,meaning having the potential to), rather than the mandatory sense (i.e.,meaning must). Similarly, the words “include,” “including,” and“includes” mean including, but not limited to.

DETAILED DESCRIPTION

Various embodiments of methods and apparatus for managing distributedapplication state using replication nodes organized as a graph, and ofdeploying such graphs to implement a logging service that can be usedfor transaction management, are described. According to someembodiments, a replicated state machine for building a fault-tolerantdistributed application may be implemented using a plurality ofreplication nodes arranged in a directed acyclic graph (DAG). In someimplementations, a particular replication DAG may include one or moreacceptor nodes, one or more committer nodes, zero or more intermediarynodes each positioned along a replication pathway comprising DAG edgesleading from an acceptor node to a committer node, and zero or morestandby nodes that are configured to quickly take over responsibilitiesof one of the other types of nodes in the event of a node failure.Acceptor, intermediary and standby nodes of a replication DAG maycollectively be referred to as “non-committer” nodes herein. “Acceptor”,“intermediary”, “committer”, and “standby” may be referred tocollectively as the set of roles that a DAG node may assume. In someembodiments, acceptor nodes may also be referred to as “head” nodes ofthe DAG, and committer nodes may also be referred to as “tail” nodes.

In general, in at least some embodiments, each node of a particularreplication DAG may be responsible for replicating state information ofat least a particular application, e.g., in the form of state transitionrecords written to a local disk or other similar storage device.Application state information may be propagated along a set of edgesfrom an acceptor node to a committer node of the DAG, referred to hereinas a replication pathway or a commit pathway. Each state transitionmessage propagated within the DAG may include a respective sequencenumber or a logical timestamp that is indicative of an order in whichthe corresponding state transition request was processed (e.g., at anacceptor node). Sequence numbers may be implemented using any of avariety of techniques in different embodiments—e.g., a simple N-bitcounter maintained by an acceptor node may be used, or a monotonicallyincreasing logical timestamp value (not necessarily related to atime-of-day clock) generated by an administrative component of the DAGsuch as the DAG's configuration manager may be used. When a particularstate transition record reaches a committer node, e.g., after asufficient number of replicas of the state transition record have beensaved along a replication pathway, the transition may be explicitly orimplicitly committed. The state of the application as of a point in timemay be determined in some embodiments as a logical accumulation of theresults of all the committed state transitions up to a selected sequencenumber. A configuration manager may be responsible for managing changesto DAG configuration (e.g. when nodes leave the DAG due to failures, orjoin/re-join the DAG) by propagating configuration-delta messagesasynchronously to the DAG nodes as described below. In some embodiments,each replication node may implement a respective deterministic finitestate machine, and the configuration manager may implement anotherdeterministic finite state machine. The protocol used for managing DAGconfiguration changes may be designed to maximize the availability or“liveness” of the DAG in various embodiments. For example, the DAG nodesmay not need to synchronize their views of the DAG's configuration in atleast some embodiments; thus, the protocol used for application statetransition processing may work correctly even if some of the nodes alonga replication pathway have a different view of the current DAGconfiguration than other nodes. It may thus be the case, in one simpleexample scenario, that one node A of a DAG continues to perform itsstate transition processing responsibilities under the assumption thatthe DAG consists of nodes A, B, C and D in that order (i.e., with areplication pathway A-to-B-to-C-to-D), while another node D has alreadybeen informed as a result of a configuration-delta message that node Chas left the DAG, and has therefore updated D's view of the DAG ascomprising a changed pathway A-to-B-to-D. The configuration manager maynot need to request the DAG nodes to pause processing of statetransition nodes in at least some embodiments, despite the potentiallydivergent views of the nodes regarding the current DAG configuration.Thus, the types of “stop-the-world” configuration synchronizationperiods that may be required in some state replication techniques maynot be needed when using replication DAGs of the kind described herein.

Under most operating conditions, the techniques used for propagating DAGconfiguration change information may eventually result in a convergedconsistent view of the DAG's configuration at the various member nodes,while minimizing or eliminating any downtime associated with nodefailures/exits, node joins or node role changes. Formal mathematicalproofs of the correctness of the state management protocols may beavailable for at least some embodiments. In at least some embodiments,the replication DAG's protocols may be especially effective in dealingwith false-positive failure detections. For example, in the aboveexample, node D may have been informed by the configuration manager thatnode C has failed, even though node C has not actually failed. Thus,state transitions may still be processed correctly by C (and by itsneighbors B and D) for some time after the false positive failuredetection, in the interval before the configuration-delta messagesindicating C's exit are received at A, B and D, enabling the applicationwhose state is being replicated to make progress despite thefalse-positive failure detection. Upon eventually being informed that ithas been removed from the DAG, C may indicate to the configurationmanager that it is in fact available for service, and may be allowed tore-join the DAG (e.g., as a standby node or in some other position alongthe modified replication pathway).

In some embodiments, an acceptor node may be responsible for receivingapplication state transition requests from a client of the replicationDAG, determining whether a particular requested transition should beaccepted for eventual commit, storing a local replica of an acceptedstate transition record, and transmitting accepted state transitionrecords to a neighbor node along a replication pathway of the DAGtowards a committer node. Depending on the use case, a state transitionrecord may include a write payload in some embodiments: e.g., if theapplication state comprises the contents of a database, a statetransition record may include the bytes that are written during atransaction corresponding to the state transition. The acceptor node mayalso be responsible in at least some embodiments for determining orgenerating the sequence number for an accepted state transition. Anintermediary node may be responsible for storing a local replica of theaccepted state transition record, and transmitting/forwarding a messageindicating the accepted state transition to the next node along thepathway to a committer node. The committer node may store its ownreplica of the state transition record on local storage, e.g., with anindication that the record has been committed. A record indicating thata corresponding state transition has been committed may be referred toherein as a “commit record”, while a record that indicates that acorresponding state transition has been accepted but has not yetnecessarily been committed may be referred to as an “accept record”. Insome embodiments, and depending on the needs of the application, thecommitter node may initiate transmission of a commit response (e.g., viathe acceptor node) to the client that requested the state transition. Inat least one embodiment, the committer node may notify some or all ofthe nodes along the replication pathway that the state transition hasbeen committed. In some embodiments, when an indication of a commit isreceived at a DAG node, the accept record for the now-committed statetransition may be replaced by a corresponding commit record, or modifiedsuch that it now represents a commit record. In other embodiments, agiven DAG node may store both an accept record and a commit record forthe same state transition, e.g., with respective sequence numbers. Insome implementations, separate commit record sets and accept record setsmay be stored in local storage at various DAG nodes, while in otherimplementations, only one type of record (accept or commit) may bestored at a time for a given state transition at a given DAG node.

A configuration manager may be designated as the authoritative source ofthe DAG's configuration information in some embodiments, responsible foraccepting changes to DAG configuration and propagating the changes tothe DAG nodes. In at least some embodiments, the configuration managermay itself be designed to be resilient to failures, e.g., as afault-tolerant cluster of nodes that collectively approve DAGconfiguration changes (such as removals or additions of nodes) viaconsensus and replicate the DAG configuration at a plurality ofconfiguration manager storage devices. As implied by the name“configuration-delta”, a message sent to a DAG node by the configurationmanager may include only an indication of the specific change (e.g., achange caused by a node joining the DAG or leaving the DAG, or a changeto a role/position of an existing node of the DAG), and need not includea representation of the DAG's configuration as a whole, or list theentire membership of the DAG. A given recipient of a configuration-deltamessage may thus be expected to construct its own view of the DAGconfiguration, based on the specific set or sequence ofconfiguration-delta messages it has received thus far. In someimplementations, sequence numbers may also be assigned toconfiguration-delta messages, e.g., to enable a recipient of aconfiguration-delta message to determine whether it has missed anyearlier configuration-delta messages. Since the configuration managermay not attempt to guarantee the order or relative timing of receivingthe configuration-delta messages by different DAG nodes, the currentviews of the DAG's configuration may differ at different nodes in someembodiments, at least for some periods of time as indicated by theexample above.

According to one embodiment, the actions taken by DAG nodes in responseto configuration-delta messages may differ based on whether theconfiguration change affects an immediate neighbor of the recipient.Consider another example scenario in which a DAG comprises an acceptornode A, an intermediary node B, and a committer node C at a point oftime T0, with the initial replication pathway A-to-B-to-C. At a time T1,the DAG's configuration manager DCM1 becomes aware that B has left theDAG, e.g., as a result of an apparent failure or loss of connectivity.DCM1 may send respective asynchronous configuration-delta messages D1and D2 respectively to remaining nodes A and C, without requesting anypause in state transition request processing. If C receives D2 at timeT2, before A receives D1 at time T3, A may continue sending statetransition messages directed to B for some time interval (T3-T2)(although, if N has in fact failed, the messages send by A may not beprocessed by B). Similarly, if A receives D1 at T2, before C receives D2at T3, C may continue to process messages it receives from B that werein flight when B failed, for some time (T3-T2) before C becomes aware ofB's departure from the DAG. When node A receives D1, if it has not yetbeen contacted by C, node A may establish connectivity to C as its newimmediate successor in the newly-configured replication pathway (A-to-C)that replaces the older replication pathway (A-to-B-to-C). Similarly,when C receives D2, it may establish connectivity to A (if A has notalready contacted C) as its new immediate predecessor, and at least insome embodiments, C may submit a request to A for re-transmissions ofstate transition records that may have been transmitted from A to B buthave not yet reached C. For example, C may include, within there-transmission request, the highest sequence number HSN1 of a statetransition record that it has received thus far, enabling A tore-transmit any state transition records with sequence numbers higherthan HSN1.

In at least some embodiments, the configuration manager may rely on ahealth detection mechanism or service to indicate when a DAG node hasapparently become unhealthy, leading to a removal of theapparently-unhealthy node from the DAG configuration. At least somehealth detection mechanisms in distributed environments may depend onheartbeats or other lower-level mechanisms which may not always make theright decisions regarding node health status. At the same time, theconfiguration manager may not be in a position to wait indefinitely toconfirm actual node failure before sending its configuration-deltamessages; instead, it may transmit the configuration-delta messages upondetermining that the likelihood of the node failure is above somethreshold (e.g., 80% or 90%), or use some other heuristics to triggerthe DAG configuration changes and corresponding delta messages. Asmentioned earlier, the state management protocols used at thereplication DAG may alleviate the negative impact of false positivefailure “detections”, e.g., by avoiding “stop-the-world” pauses. As aresult, it may be possible to use faster/cheaper (although potentiallyless reliable) failure-checking mechanisms when replication DAGs areemployed than would have been acceptable if other state replicationtechniques were used.

In at least one embodiment, a coordinated suspension technique may beimplemented for replication DAGs. Under certain conditions, e.g., if alarge-scale failure event involving multiple DAG resources or nodes isdetected, the configuration manager may direct the surviving nodes ofthe DAG to stop processing further state transitions, synchronize theirapplication state information with each other, store the synchronizedapplication state information at respective storage locations, and awaitre-activation instructions. In some implementations, after savingapplication state locally, the DAG nodes may each perform a cleanshutdown and restart, and report to the configuration manager afterrestarting to indicate that they are available for service. If a nodethat had failed before the suspend command was issued by theconfiguration manager reports that it is available for service, in someembodiments the configuration manager may direct such a node tosynchronize its application state with another node that is known (e.g.,by the configuration manager) to be up-to-date with respect toapplication state. The configuration manager may wait until a sufficientnumber of nodes are (a) available for service and (b) up-to-date withrespect to application state, determine a (potentially new) DAGconfiguration, and re-activate the DAG by sending re-activation messagesindicating the DAG configuration to the member nodes of theconfiguration. Such a controlled and coordinated suspension/restartstrategy may allow more rapid and dependable application recovery afterlarge-scale failure events than may have been possible otherwise in someembodiments. The coordinated suspension approach may also be used forpurposes other than responding to large-scale failures—e.g., for fastparallel backups/snapshots of application state information from aplurality of the replication nodes.

DAG-based replicated state machines of the type described above may beused to manage a variety of different applications in variousembodiments. In some embodiments, a logging service may be implemented,at which one or more data stores (e.g., relational or non-relationaldatabases) may be registered for transaction management via an instanceof a persistent change log implemented using a replication DAG. Asdescribed below in further detail, an optimistic concurrency controlmechanism may be used by such a log-based transaction manager in someembodiments. A client of the logging service may perform read operationson one or more source data stores and determine one or more data storelocations to which write operations are to be performed (e.g., based onthe results of the reads) within a given transaction. A transactionrequest descriptor including representations of the read sets, writesets, concurrency control requirements, and/or logical constraints onthe transaction may be submitted to a conflict detector of the loggingservice (e.g., conflict detection logic associated with an acceptor nodeof the corresponding replication DAG). The conflict detector may userecords of previously-committed transactions together with the contentsof the transaction descriptor to determine whether the transactionrequest is acceptable for commit. If a transaction is accepted forcommit, a replication of a corresponding commit record may be initiatedat some number of replication nodes of the DAG established for the log.The records inserted into a given replica of the log may thus eachrepresent respective application state transitions. A number ofdifferent logical constraints may be specified in different embodiments,and enforced by the log-based transaction manager, such asde-duplication requirements, inter-transaction commit sequencingrequirements and the like. Such a log-based transaction managementmechanism may, in some embodiments, enable support for multi-itemtransactions, or multi-database transactions, in which for example agiven transaction's write set includes a plurality of write locationseven though the underlying data stores may not natively supportatomicity for transactions involving more than one write. The writescorresponding to committed transactions may be applied to the relevantdata stores asynchronously in at least some embodiments—e.g., a recordthat a transaction has been committed may be saved in the persistentchange log at some time before the corresponding writes are propagatedto the targeted data stores. The persistent change log may thus becomethe authoritative source of the application state in at least someembodiments, with the data stores catching up with the application stateafter the log has recorded state changes.

Replication DAGs may also be used for replicated database instances, formanaging high-throughput data streams, and/or for distributed lockmanagement in various embodiments. In some embodiments, replication DAGsmay be used within provider networks to manage state changes tovirtualized resources such as compute instances. In at least someembodiments, in addition to propagating committed writes to registereddata stores (from which the results of the writes can be read via therespective read interfaces of the data stores), a logging service mayalso define and implement its own separate access interfaces, allowinginterested clients to read at least a portion of the records stored fora given client application directly from a persistent log instance.

Example System Environment

FIG. 1 illustrates an example system environment in which a dynamic DAG(directed acyclic graph) of replication nodes is established formanaging application state changes, according to at least someembodiments. As shown, in system 100, replication DAG 140 establishedfor managing state transitions of an application 160 comprises areplication pathway with three nodes: an acceptor node 110, anintermediate node 112 and a committer node 114. In addition, DAG 140includes a standby node 130 in the depicted embodiment, available totake over the responsibilities of any of the other nodes if needed.Other combinations of nodes may be deployed for other replicationDAGs—e.g., more than one intermediate node may be used for someapplications, no intermediate nodes may be used for other applications,or standby nodes may not be established. Changes to the configuration ofthe DAG 140 may be coordinated by a fault-tolerant DAG configurationmanager (DCM) 164 as described below.

The acceptor node 110 may receive application state transition requests(STRs) 150 via one or more programmatic interfaces such as APIs(application programming interfaces) in the depicted embodiment. Theacceptor node 110 may accept a requested transition for an eventualcommit, or may reject the request, using application-dependent rules orlogic. If a transition is accepted, a sequence number may be generatedby the acceptor node 110, e.g., indicative of an order in which thattransition was accepted relative to other accepted transitions. Asmentioned above, in some embodiments the sequence number may comprise acounter that is incremented for each accepted transition, while in otherembodiments a logical clock or timestamp value provided by theconfiguration manager may be used. A collection 176A of applicationstate records (ASRs) 172A including corresponding sequence numbers maybe stored in local persistent storage by the acceptor node. In someembodiments, the application state records may comprise both transitionaccept records and transition commit records (with a commit record beingstored only after the acceptor node is informed that the correspondingtransition was committed by the committer node). In other embodiments,at least some nodes along the replication pathway may only store acceptrecords. After storing a state transition record indicating acceptance,the acceptor node may transmit a state transition message (STM) 152Aindicating the approval to its successor node along the replicationpathway, such as intermediate node 112 in the illustrated configuration.The intermediate node may store its own copy of a corresponding ASR,172B, together with the sequence number, in its local ASR collection176B. The intermediate node may transmit its own STM 152B to itsneighbor along the current replication pathway, e.g., to committer node114 in the depicted embodiment. In at least some implementations, theSTMs 152 may include an indication of which nodes have already storedreplicas of the ASRs—e.g., the message 152B may indicate to thecommitter node that respective replicas of the application state recordindicating acceptance have been stored already at nodes 110 and 112respectively.

In response to a determination at the committer node that a sufficientnumber of replicas of the application state record have been stored(where the exact number of replicas that suffice may be a configurationparameter of the application 160), the transition may be committed. TheASR collection 176C of the committer node may comprise records oftransaction commits (as opposed to approvals) in the depictedembodiment; thus, ASR 172C may indicate a commit rather than just anacceptance. In at least some embodiments, the committer node 116 maytransmit indications or notifications to the acceptor node and/or theintermediate node indicating that the transition was committed. In otherembodiments, the acceptor and/or intermediate node may submit requests(e.g., periodically) to the committer node 116 to determine whichtransitions have been committed and may update their ASR collectionsaccordingly. For some applications, explicit commits may not berequired; thus, no indications of commits may be stored, and each of theDAG nodes along the pathway may simply store respective applicationstate records indicating acceptance. In the depicted embodiment,post-commit STMs 154 may be transmitted from the committer node to thestandby node 130 to enable the standby node to update its ASR collection176D (e.g., by storing a commit ASR 172D), so that if and when thestandby node is activated to replace another DAG node, its applicationstate information matches that of the committer node. The fact thatstandby nodes are kept up-to-date with the latest committed applicationstate may enable the configuration manager to quickly activate a standbynode for any of the other three types of roles in some embodiments:e.g., as an acceptor node, an intermediate node, or a committer node.

A fault-tolerant DAG configuration manager (DCM) 164 may be responsiblefor propagating changes to the DAG configuration or membership in theform of configuration-delta messages 166 (e.g., messages 166A, 166B,166C and 166D) to the DAG nodes as needed in the depicted embodiment.When a given DAG node leaves the DAG 140, e.g., as a result of afailure, a corresponding configuration-delta message 166 may be sent toone or more surviving nodes by the DCM 164, for example. Similarly, whena new node joins the DAG (e.g., after a recovery from a failure, or toincrease the durability level of the application 160), a correspondingconfiguration-delta message indicating the join event, the position ofthe joining node within the DAG, and/or the role (e.g., acceptor,intermediate, committer, or standby) granted to the joining node may betransmitted by the DCM to one or more current member nodes of the DAG.The configuration-delta messages 166 may be asynchronous with respect toeach other, and may be received by their targets in any order withoutaffecting the overall replication of application state. Each node of theDAG may be responsible for constructing its own view 174 of the DAGconfiguration based on received configuration-delta messages,independently of the configuration views 174 that the other nodes mayhave. Thus, for example, because of the relative order and/or timing ofdifferent configuration-delta messages received at respective nodes 110,112, 114 and 130, one or more of the configuration views 174A, 174B,174C and 174D may differ at least for some short time intervals in someembodiments. In at least some embodiments, each DAG node may storerepresentations or contents of some number of the configuration-deltamessages received in respective local configuration change repositories.In the depicted embodiment, the DCM 164 may not enforce stop-the-worldpauses in application state processing by the DAG nodes—e.g., it mayallow the nodes to continue receiving and processing application statetransition messages regardless of the timing of configuration-deltamessages or the underlying DAG configuration changes. Examples of themanner in which DAG nodes respond to configuration-delta messages arediscussed below with reference to FIG. 2a -2 h.

It is noted that although FIG. 1 shows a DAG with a single linearreplication pathway or “chain” with one node of each type, in at leastsome embodiments a replication DAG may include branched pathways and/ormultiple nodes for each role. That is, several acceptor, intermediate,committer and/or standby nodes may coexist in the same DAG, and theDAG's replication pathways may include join nodes (nodes at whichtransition requests from multiple predecessor nodes are received) orsplit nodes (nodes from which transition requests are sent to multiplesuccessor nodes). If either the acceptor node 110 or the committer node116 rejects a requested state transition (e.g., either because theacceptor node determines a set of application-specific acceptancecriteria are not met, or because an insufficient number of replicas ofan accepted transition have been made by the time the committer nodereceives the accepted state transition request message), in someembodiments the client that requested the transition may be informedthat the transition was not committed. The client may then retry thetransition (e.g., by submitting another state transition request), ormay decide to abandon the request entirely. In some implementations,intermediate nodes may also be permitted to abort transition requests.

FIG. 2a-2h illustrate an example sequence of operations that may beperformed at a replication DAG in response to a detection that one ofthe nodes of the DAG may have failed, according to at least someembodiments. FIG. 2a shows an initial state of the DAG configuration,including three nodes 202A, 202B and 202C. State transition requests(STRs) 150 are received at node 202A. Accepted state transition recordsare replicated at nodes 202A (after local approval of the STRs) and 202B(after node 202B receives approved STMs 211A), and committed at 202C(after node 202C receives approved STMs 211B). The DCM 164 may receive ahealth status update 250 indicating that node 202B has apparentlyfailed. The health status update regarding node 202B's status may bereceived from any of a variety of sources in different embodiments,e.g., from one of the other nodes (202A or 202B), or from a healthmonitoring service external to the DAG (e.g., a general-purpose resourcehealth monitoring service established at a provider network where theDAG nodes are instantiated). In at least one implementation, the healthstatus update may be generated by a subcomponent of the DMC 164 itself,such as a monitoring process that periodically sends heartbeat messagesto the DAG nodes and determines that a given node is in an unhealthystate if no response is received within an acceptable time window tosome number of successive heartbeat messages.

In the depicted embodiment, the DCM 164 may decide on the basis of thehealth status update that node 202B should be removed from the DAG, anda new node 202D should be added as a successor to node 202C. The newnode may, for example, comprise a standby node being promoted to activestatus as the new committer node of the DAG. After deciding the newconfiguration of the DAG (i.e., that the DAG should now comprise areplication chain 202A-to-202C-to-202D), and saving a representation ofthe new configuration in a persistent repository, DCM 164 may issue acommand 241 to node 202D to join the DAG as a successor to node 202C. Itis noted that at least in some embodiments, a removal of a node such as202B from a DAG may not necessarily be accompanied by an immediateaddition of a replacement node (especially if the number of DAG nodesthat remain online and connected after the removal exceeds the minimumnumber of nodes needed by the application whose state is beingreplicated); the addition of node 202D is illustrated simply as one ofthe ways in which the DCM may respond to a node failure (or at least anapparent node failure). As shown in FIG. 2b , it may be the case thatnode 202B has not actually failed (i.e., that the health update was inerror regarding 202B's failure). In such a false-positive scenario,state transition messages may continue to be transmitted from 202Atowards 202B, and from 202B to 202C, allowing the application tocontinue making progress for at least some time after the DCM 164 makesthe removal decision.

In at least some embodiments, when a node such as 202B is removed from aDAG, and the immediate successor (e.g., 202C) of the removed noderemains in the DAG, the role that was previously assigned to the removednode may be transferred to the immediate successor. Thus, node 202C,which may have been a committer node, may be made an intermediate nodeupon node 202B's departure, and the newly-activated node 202D may bedesignated as the new committer node. If the removed node had noimmediate successor (e.g., if node 202C had been removed in the depictedexample instead of node 202B), the newly-activated standby node may begranted the role that was assigned to the removed node in someembodiments. In other embodiments, roles may not be transferred in asuch a sequential/linear fashion—e.g., the configuration manager maydecide which roles should be granted to a given node without taking therelative position of the node vis-à-vis a removed node into account.

After deciding that node 202B should be removed from the DAG, the DCM164 may send respective asynchronous configuration-delta messages 242Aand 242B to nodes 202A and 202C in the depicted embodiment. As shown,each of the delta messages may indicate that 202B has left the DAG, andthat 202D has joined. Although the two changes to the configuration areindicated in a single configuration-delta message in the depictedembodiment, in other embodiments separate configuration delta messagesmay be sent for the removal of 202B and the join of 202D. Theconfiguration-delta messages may indicate only the changes to the DAGconfiguration, and may not comprise a representation of the DAG's entireconfiguration in the depicted embodiment. Until node 202A receives theconfiguration-delta message 242A or otherwise becomes aware that 202Bhas left the DAG (e.g., due to termination of a network connection),STMs may continue to be directed from node 202A to node 202B. In thescenario where 202B has not actually failed, node 202B may continueprocessing state transition requests and sending messages 211B towardsnode 202C until it becomes aware that it has been removed from the DAG(e.g., if either 202A or 202C stop communicating with 202B).

Since the configuration-delta messages 242 are sent using anasynchronous messaging mechanism, they may arrive at their destinationsat different times. If node 202A receives configuration-delta message242A before node 202C receives configuration-delta message 242B, thescenario depicted in FIG. 2d may be reached (in which the DAG at leasttemporarily contains a branch). In response to message 242A, node 202Amay save the indication of the configuration change in local storage andstop sending any further messages to node 202B. Furthermore, node 202Amay determine that its new successor node is 202C, and may thereforeestablish network connectivity with node 202C and start sending node202C new state transition messages 211C. In the embodiment depicted,state transition processing activities may continue at various nodes ofthe DAG even as the message indicating the removal of 202B makes its wayto the remaining nodes. In a scenario in which node 202B is assumed tohave failed but in fact remains functional, for example, even after node202A learns that node 202B has been removed from the DAG, one or morein-flight state transition messages may be received from node 202A atnode 202B. Upon receiving such an in-flight message, node 202B mayreplicate the state transition information indicated in the message inlocal storage and attempt to transmit another similar STM to node 202C.If node 202C has not yet learned of node 202B's removal (or at least hasnot yet closed its connection with node 202B), node 202C may receive andprocess the message from node 202B, allowing the application to makeprogress, even though node 202B has been removed from the DAGconfiguration by the configuration manager.

If node 202C receives configuration-delta message 242B before node 202Areceived configuration-delta message 242A, the scenario illustrated inFIG. 2e may be reached. Upon receiving message 242B, node 202C may stopreceiving new messages sent from node 202B (e.g., by terminating itsconnection with node 202B if the connection is still in service). Uponrealizing that node 202A is its new immediate predecessor in the DAGpathway, node 202C may establish connectivity to node 202A. Node 202Cmay also determine the highest sequence number HSN1 (from among thesequence numbers for which approved STMs have already been received atnode 202C), and send a request 260 to node 202A to re-transmit anyapproved state transition messages that 202C may have missed (i.e., anyapproved STMs with higher sequence numbers than HSN1) in the depictedembodiment. Furthermore, node 202C may also establish connectivity toits new successor node 202D, and may start sending subsequent approvedSTMs 211D to node 202D.

After both nodes 202A and 202C have been informed about the DAGconfiguration change, the DAG's new replication pathway illustrated inFIG. 2f (i.e., 202A-to-202C-to-202D) may be used for new incoming statetransition requests. It is noted that because of the timing of theconfiguration-delta messages 242, it may be the case that node 202Alearns about the configuration change from node 202C before theconfiguration-delta message 242A is received at node 202A. Similarly,node 202C may learn about the new configuration from node 202A (or evennode 202D) in some embodiments. Thus, there may be multiple ways inwhich information about the new configuration may reach any given nodeof the DAG, and at least in some embodiments the DAG nodes may startusing portions of the new replication pathway even before theconfiguration-delta messages have reached all of their targetedrecipients.

As shown in FIG. 2g , at some point after it has been removed from theDAG (e.g., either due to an actual failure or due to a false positivefailure detection), node 202B may optionally indicate to the DCM 164that it is ready for service. In the case of an actual failure, forexample, node 202B may eventually be repaired and restarted and mayperform some set of recovery operations before sending the “availablefor service” message 280. In the case of a network connectivity loss,the “available for service” message may be sent after connectivity isreestablished. In response, in the depicted embodiment, the DCM 164 maydecide to add node 202B back as a standby node of the DAG. Accordingly,as shown in FIG. 2h , the DCM may send a join command 282 to node 202B,and a new set of configuration-delta messages 244A, 244B and 244C tonodes 202A, 202B and 202D respectively to inform them of the addition ofnode 202B. It is noted that the sequence of operations illustrated inFIG. 2a-2h is provided as an example, and that the DAG nodes and the DCMmay perform a different sequence of operations than that illustrated inFIG. 2a-2h in response to an apparent failure of node 202B in variousembodiments. For example, no new node may be added to the DAG in someembodiments as a successor to node 202C. Also, in some embodiments, node202B may not necessarily re-join the same DAG after it becomes availablefor service; instead, for example, it may be deployed to a different DAGor may be kept in a pool of nodes from which new DAGs may be configured.

Although a detection of a failure is shown as triggering a DAGconfiguration changes in FIG. 2a-2h , in general, any of a number ofdifferent considerations may lead to modifications of DAG configurationsin various embodiment. For example, an application owner (or the DCM)may decide to add a node to a DAG to enhance data durability or foravailability reasons. Configuration-delta messages indicating theaddition of a new node may be propagated in a similar asynchronousfashion to other DAG nodes as the removal-related propagation describedabove in some embodiments, without requiring “stop-the-world” pauses instate transition processing. A DAG node may have to be taken offline formaintenance-related reasons in some embodiments, e.g., for a softwareupgrade, for debugging software errors, or for hardware modifications.In at least one embodiment, a DAG's configuration may be changed as aresult of a determination that the workload level (e.g., the number ofstate transitions being processed per second) at one or more of thenodes has reached a threshold level, and that more performant (or lessperformant) hardware/software stacks should be utilized than are beingused currently. In some embodiments, a DAG configuration change mayinvolve changing the position or role of a particular DAG node, withoutnecessarily adding or removing a node. For example, a configurationmanager may switch the role of committer to a node that was previouslyan intermediate node, and make the old committer node an intermediatenode in the new configuration. Such a role change may be implemented(and the corresponding configuration-delta messages propagated), forexample, for load balancing purposes, especially in a multi-tenantenvironment in which the same host is being used for nodes of severaldifferent DAGs. Such multi-tenant environments are described below infurther detail.

State Transition Records and Configuration-Delta Messages

FIG. 3 illustrates example components of application state records(ASRs) and DAG configuration-delta messages that may be generated at adynamic replication DAG according to at least some embodiments. Asindicated earlier, copies of application state records, eachrepresenting an approved or committed state transition, may be stored ateach of several nodes along a replication pathway of a DAG in at leastsome embodiments Application state records may also be referred to asstate transition records herein. As shown, an application state record320 may comprise an indication of the type 302 of the transition—e.g.,whether an approval of a requested state transition is being recorded,or whether a commit of an approved state transition is being recorded.In some embodiments, as noted earlier, each DAG node may store bothapproval and commit records, while in other embodiments, only one typeof state transition record may be stored. For example, in one scenario,approval records may be replicate initially at non-committer nodes, andthe approval records may be changed to commit records after thetransaction is eventually committed by the committer node. In at leastone embodiment, a separate transition type field 302 may not be includedin an ASR or in the message that leads to the generation of theASR—instead, the type of the transition may be inferred by a DAG nodebased on the node's knowledge of its current role and/or the role of thesource DAG node from which the message is received. For example, anon-committer node that receives a state transition message may inferthat the message represents an approved state transition.

The state transition records 320 records may include transition data 304in the depicted embodiment. The nature of the contents of the transitiondata component 304 may differ depending on the application whose stateis being managed. In some cases, for example, a state transition requestmay include a write payload (indicating some number of bytes that are tobe written, and the address(es) to which the bytes are to be written),and the write payload may be included in the transition record. Forother applications, each state transition may indicate a respectivecommand issued by an application client, and a representation of thecommand may be included in the ASR. The ASR 320 may also include asequence number 306 (which may also be considered a logical timestamp)corresponding to the state transition. The sequence number may, forexample, be generated at an acceptor node when a state transitionrequest is approved, or at a committer node when the state transition iscommitted. In at least some embodiments, the current state of theapplication being managed using the DAG may be determined by applying,starting at some initial state of the application, transition data ofcommitted state records (e.g., write payloads, commands, etc.) in orderof increasing sequence numbers. In some embodiments, replication historyinformation 308 of a transition may also be included in an ASR—e.g.,indicating which DAG nodes have already stored a respective ASR for thesame transition, and/or the order tin which those records have beenreplicated. Such replication history information may, for example, beused by a committer node in some implementations to confirm that asufficient number of nodes have recorded a given state transition for acommit. In some embodiments, an ASR message may indicate the identity ofthe acceptor node where the corresponding state transition request wasreceived, but need not include information regarding other nodes alongthe replication pathway. In at least one implementation, a committernode may not be required to confirm that a sufficient number of nodeshave replicated a state transition record before committing an approvedstate transition.

A DAG configuration-delta message 370 may indicate an identifier 352 ofthe node (or nodes) joining or leaving the configuration in the depictedembodiment, and the type of change 354 (e.g., join vs. leave) beingimplemented. In some implementations, role information 356 about thejoining (or leaving) node may optionally be included in theconfiguration-delta message. In at least some embodiments, just asapplication state sequence numbers are associated with application statetransitions, DAG configuration change sequence numbers 358 may beincluded with configuration-delta messages. Such sequence numbers may beused by a recipient of the configuration-delta messages to determinewhether the recipient has missed any prior configuration changes, forexample. If some configuration changes have been missed (due to networkpackets being dropped, for example), the recipient node may send arequest to the DCM to re-transmit the missed configuration-deltamessages. The configuration change sequence numbers 358 may beimplemented as counters or logical timestamps at the DCM in variousembodiments. In some implementations in which the DCM comprises acluster with a plurality of nodes, a global logical timestamp maintainedby the cluster manager may be used as a source for the configurationchange sequence numbers 358.

Replication DAG Deployments in Provider Network Environments

FIG. 4 illustrates an example replication DAG whose member nodes aredistributed across a plurality of availability containers of a providernetwork, according to at least some embodiments. Networks set up by anentity such as a company or a public sector organization to provide oneor more services (such as various types of multi-tenant and/orsingle-tenant cloud-based computing or storage services) accessible viathe Internet and/or other networks to a distributed set of clients maybe termed provider networks herein. At least some provider networks mayalso be referred to as “public cloud” environments. A given providernetwork may include numerous data centers hosting various resourcepools, such as collections of physical and/or virtualized computerservers, storage devices, networking equipment and the like, needed toimplement, configure and distribute the infrastructure and servicesoffered by the provider. Within large provider networks, some datacenters may be located in different cities, states or countries thanothers, and in some embodiments the resources allocated to a givenapplication may be distributed among several such locations to achievedesired levels of availability, fault-resilience and performance.

In some embodiments a provider network may be organized into a pluralityof geographical regions, and each region may include one or moreavailability containers, which may also be termed “availability zones”.An availability container in turn may comprise one or more distinctphysical premises or data centers, engineered in such a way (e.g., withindependent infrastructure components such as power-related equipment,cooling equipment, and/or physical security components) that theresources in a given availability container are insulated from failuresin other availability containers. A failure in one availabilitycontainer may not be expected to result in a failure in any otheravailability container; thus, the availability profile of a givenphysical host or virtualized server is intended to be independent of theavailability profile of other hosts or servers in a differentavailability container.

One or more nodes of a replication DAG may be instantiated in adifferent availability container than other nodes of the DAG in someembodiments, as shown in FIG. 4. Provider network 402 includes threeavailability containers 466A, 466B and 466C in the depicted embodiment,with each availability container comprising some number of node hosts410. Node host 410A of availability container 466A, for example,comprises a DAG node 422A, local persistent storage (e.g., one or moredisk-based devices) 430A, and a proxy 412A that may be used as a frontend for communications with DAG clients. Similarly, node host 410B inavailability container 466B comprises DAG node 422B, local persistentstorage 430B, and a proxy 412B, and node host 410C in availabilitycontainer 466C includes DAG node 422C, local persistent storage 430C anda proxy 412C. In the depicted embodiment, DAG nodes 422 (and/or proxies412) may each comprise one or more threads of execution, such as a setof one or more processes. The local persistent storage devices 430 maybe used to store local replicas of application state information alongreplication path 491 (and/or DAG configuration-delta message contentsreceived at the DAG nodes 422 of the replication path 491) in thedepicted embodiment.

The DCM of the DAG depicted in the embodiment of FIG. 4 itself comprisesa plurality of nodes distributed across multiple availabilitycontainers. As shown, a consensus-based DCM cluster 490 may be used,comprising DCM node 472A with DCM storage 475A located in availabilitycontainer 466A, and DCM node 472B with DCM storage 475B located inavailability container 466B. The depicted DCM may thus be consideredfault-tolerant, at least with respect to failures that do not crossavailability container boundaries. The nodes of such a fault-tolerantDCM may be referred to herein as “configuration nodes”, e.g., incontrast to the member nodes of the DAG being managed by the DCM.Changes to the DAG configuration (including, for example, node removals,additions or role changes) may be approved using a consensus-basedprotocol among the DCM nodes 472, and representations of the DAGconfiguration may have to be stored in persistent storage by a pluralityof DCM nodes before the corresponding configuration-delta messages aretransmitted to the DAG nodes 422. The number of availability containersused for the DCM and/or for a given replication DAG may vary indifferent embodiments and for different applications, depending forexample on the availability requirements or data durability requirementsof the applications. In some embodiments, replication DAGs may be usedto manage the configuration of resources of other services implementedat a provider network. For example, changes to the state of computeinstances (virtual machines) or instance hosts (physical hosts) used bya virtualized computing service may be managed using a replication DAGin one embodiment.

FIG. 5 illustrates an example configuration in which nodes of aplurality of replication DAGs may be implemented at a single host in amulti-tenant fashion, according to at least some embodiments. As shown,nodes of three replication DAGs 555A, 555B and 555C are distributedamong four DAG node hosts 510A, 510B, 510C and 510D. In general, thenode hosts may differ in their resource capacities—e.g., the computing,storage, networking and/or memory resources of one host may differ fromthose of other hosts. For example, node host 510B has two storagedevices 530B and 530C that can be used for DAG information, node host510D has two storage devices 530E and 530F, while node hosts 510A and510C have one storage device (530A and 530D respectively).

Host 510A comprises an acceptor node 522A of DAG 555A, and anintermediate node 522N of DAG 555C. Host 510B comprises an intermediatenode 522B of DAG 555A, a committer node 522K of DAG 555B, and anintermediate node 522O of DAG 555C. Committer node 522C of DAG 555A andcommitter node 522P of DAG 555C may be implemented at host 510C.Finally, standby node 522C of DAG 555A, acceptor node 522J of DAG 555B,and acceptor node 522M of DAG 555C may be instantiated at host 510D.Thus, in general, a given host may be used for nodes of N differentDAGs, and each DAG may utilize M different hosts, where M and N may beconfigurable parameters in at least some embodiments. Nodes of severalDAGs established on behalf of respective application owners may beimplemented on the same host in a multi-tenant fashion in at least someembodiments: e.g., it may not be apparent to a particular applicationowner that the resources being utilized for state management of theirapplication are also being used for managing the state of otherapplications. In some provider network environments, a placement servicemay be implemented that selects the specific hosts to be used for agiven node of a given application's replication DAG. Node hosts may beselected on the basis of various combinations of factors in differentembodiments, such as the performance requirements of the applicationwhose state is being managed, the available resource capacity atcandidate hosts, load balancing needs, pricing considerations, and soon. In at least some implementations, instantiating multiple DAG nodesper host may help to increase the overall resource utilization levels atthe hosts relative to the utilization levels that could be achieved ifonly a single DAG node were instantiated. For example, especially inembodiments in which a significant portion of the logic used for a DAGnode is single-threaded, more of the processor cores of a multi-corehost could be used in parallel in the multi-tenant scenario than in asingle-tenant scenario, thereby increasing average CPU utilization ofthe host.

Methods for Implementing Dynamic DAG-Based State Replication

As discussed above, a given node of a replication DAG may be granted oneof a number of roles (e.g., acceptor, intermediate, committer, orstandby) in some embodiments at a given point in time. FIG. 6 is a flowdiagram illustrating aspects of operations that may be performed at anacceptor node of a replication DAG in response to receiving a statetransition request (STR), according to at least some embodiments. Asshown in element 601, the acceptor node may receive a message comprisingan STR for an application, e.g., from a client of a state replicationservice. The STR may comprise various elements in different embodiments,depending in part on the nature of the application. For example, in someembodiments as described below in greater detail, the DAG may be usedfor optimistic concurrency control for transactions directed at one ormore data stores, and the STR may include data such as read sets andwrite sets that can be used to detect conflicts withpreviously-committed transactions. Each application whose statetransitions are managed using a replication DAG may have its own set ofacceptance criteria for requested state transitions, and at least insome cases the contents of the STR may be used to decide whether thetransition should be accepted or rejected. In some implementations,operational conditions may also or instead be used foraccepting/rejecting requested state transitions—e.g., if the workloadlevel at the acceptor node or at other nodes of the DAG is at or above athreshold, the state transition may be rejected. If the transition meetsthe acceptance criteria (as detected in element 604), a new approvalsequence number may be generated for the accepted STR (element 607),e.g., by incrementing a counter value or by obtaining some othermonotonically increasing logical timestamp value. A record indicatingthat the transition was approved may be stored in local storage,together with the sequence number (element 610). For some applications,transition requests may include a data set (such as a write payload) tobe replicated, the acceptor node may store the data set in local storageas well. In one implementation the acceptor node may comprise one ormore processes running at a particular host of a provider network, andthe a record of the transition's approval, the sequence number and thetransition's data set may all be stored at a persistent disk-basedstorage device of the particular host. In some embodiments, thetransition's data, an indication that the transition was approved, andthe sequence number may all be combined into a single object stored atlocal storage, such as a log entry inserted into (or appended to) a log.In other embodiments, the transition's data set may be stored separatelyfrom the records indicating approval of the transition.

After the record of the state transition is safely stored, a statetransition message indicating the approval may be transmitted to aneighbor node along a replication path of the DAG (element 613) towardsa committer node. In some cases, depending on the topology of the DAG,multiple such messages may be sent, one to each neighbor node along thereplication path. As described earlier, each node of the DAG may haveits own view of the DAG configuration, which may not necessarilycoincide with the views of the other nodes at a given point in time. Theacceptor node may direct its approved state transition messages to theneighbor node(s) indicated in its current view of the DAG'sconfiguration in the depicted embodiment, even if that current viewhappens to be obsolete or incorrect from the perspective of the DCM ofthe DAG (or from the perspective of one or more other DAG nodes). Afterthe message(s) are sent, the state transition request's processing maybe deemed complete at the acceptor node (element 619). If the requestedtransition does not meet the acceptance criteria of the application (asalso detected in element 604), the transition may be rejected (element616). In some implementations, a notification or response indicating therejection may be provided to the requester.

FIG. 7 is a flow diagram illustrating aspects of operations that may beperformed at an intermediate node of a replication DAG in response toreceiving an approved state transition message, according to at leastsome embodiments. After such a message STM1 is received (element 701),e.g., from an acceptor node or from another intermediate node, in someembodiments the intermediate node may determine whether state transitionmessages with lower sequence numbers are missing (e.g., if STM1 has asequence number of SN1, whether one or more STMs with smaller sequencenumbers than SN1 have not yet been received). If evidence of suchmissing state transition messages is found (element 704), theintermediate node may optionally submit a retransmit request for themissing STM(s) to immediate predecessor nodes along currently-knownreplication paths (element 707) in the depicted embodiment. In someimplementations, the intermediate node may wait to receive responses toits retransmit request before storing a record of the approved statetransition corresponding to STM1 in local storage. The approve recordfor STM1 may be stored, e.g., together with the approval sequence numberand any data set (such as a write payload) associated with thetransition (element 710). A state transition message (which may besimilar in content to the message that was received, or identical incontent to the message that was received) may then be sent to eachneighbor node on the currently-known replication path(s) towards acommitter node (element 713). In some implementations in which a statetransition's approval history is included within state transitionmessages, the intermediate node may add its (the intermediate node's)identifier to the list of approvers indicated in the outgoing statetransition message.

In some embodiments, instead of checking for missing sequence numbersbefore saving the approval record for STM1 in local storage, a differentapproach may be taken. For example, the intermediate node may check formissing sequence numbers after storing the approval record in localstorage and/or after transmitting a corresponding STM towards thecommitter node.

In one implementation, a networking protocol such as TCP (theTransmission Control Protocol) that guarantees in-order delivery ofmessages within a given connection may be used in combination with apull model for receiving STMs at non-acceptor nodes. In such animplementation, as long as an intermediate node, committer node orstandby node maintains a network connection with its immediatepredecessor along a replication path, the networking protocol may berelied upon to ensure that no messages are lost. If, at a given DAG nodeN1, the connection to the immediate predecessor node P1 is lost in suchan implementation, N1 may be responsible for establishing a newconnection to P1 (or to a different predecessor node if aconfiguration-delta message has been received indicating that P1 is nolonger part of the DAG), and requesting P1 to send any STMs withsequence numbers higher than the previously highest-received sequencenumber.

FIG. 8 is a flow diagram illustrating aspects of operations that may beperformed at a committer node of a replication DAG in response toreceiving an approved state transition message, according to at leastsome embodiments. Upon receiving an approved state transition message(element 801), e.g., from an intermediate node or from an acceptor node,the committer node may determine whether the state transition meets theapplication's commit criteria. In some embodiments, the committer nodemay be able to determine, from the contents of the STM (such as anapproval history field), the number of replicas of application staterecords that have been saved thus far, and the transition may be deemedcommittable if the number of replicas exceeds a threshold. The replicacount thresholds may differ based on the application; for example, asingle replica at the acceptor node may be sufficient for someapplications. In other embodiments, the committer node may also have toconsider other factors before committing the transition, such as whetherthe committer node has already received all the STMs with lower sequencenumbers than the current STM's sequence number. In one embodiment, forexample, the committer node may have to wait until it receives andprocesses all such prior STMs before committing the current transition.

If the commit criteria (which may differ from application toapplication) are met (as detected in element 804), the committer nodemay store a commit record within its collection of application staterecords in local storage (element 807), e.g., together with the sequencenumber and the transition's data set (if any). In some implementations,the commit criteria may default to the acceptance criteria that havealready been verified at the acceptor node—that is, once the statetransition has been approved at an acceptor node, the committer node maycommit the state transition indicated in a received STM without havingto verify any additional conditions. In some embodiments, a copy of theapproval sequence number indicated in the STM may be stored as thecommit sequence number. Since some approved transitions may not getcommitted, in at least one embodiment a different set of sequencenumbers may be used for commits than is used for approvals (e.g., sothat the sequence of commit sequence numbers does not have any gaps). Ifstandby nodes are configured for the DAG, post-commit STMs may bedirected to one or more such standby nodes from the committer node. Inat least some embodiments, after the transition is committed, anotification of the commit may be provided to one or more other nodes ofthe DAG (element 810), e.g., to enable the other nodes to update theirapplication state information and/or for transmitting a response to thestate transition's requesting client indicating that the transition hasbeen committed.

In some embodiments in which missing STMs were not handled as part ofthe processing related to commit criteria, the committer node may takesimilar actions as were indicated in FIG. 7 with respect to missingSTMs. Thus, for example, if the committer node determines that one ormore STMs are missing (with lower sequence numbers than the sequencenumber of the received STM) (element 813), a retransmit request for themissing STMs may be sent to the immediate predecessor node(s) (element816) to complete processing of the received STM (element 822). If thecommit criteria were not met, the committer node may abort the statetransition (element 819). In some embodiments, an abort notification maybe sent to one or more other nodes of the DAG, and/or to the client thatrequested the state transition. In some implementations, as mentionedabove, if a state transition has been approved at an acceptor node, thereplication DAG may be responsible for (eventually) committing the statetransition even if one or more nodes of the replication pathway(including the acceptor node itself) fail. Aborting a state transitionmay require a relatively heavyweight change in some suchimplementations, such as the removal of approval records of thetransition from other DAG nodes (or the actual removal from the DAG ofthe nodes at which approval records happen to be stored). As describedbelow in further detail with respect to FIG. 11a -FIG. 14, a preemptivecoordinated DAG suspension technique may be used in some embodiments toavoid scenarios in which STMs reach committer nodes without thecorresponding state transition information having been replicated at adesired number of DAG nodes.

FIG. 9 is a flow diagram illustrating aspects of operations that may beperformed at a configuration manager (DCM) of a replication DAG,according to at least some embodiments. As shown in element 901, anevent that can potentially trigger a configuration change at a DAG maybe detected by the configuration manager. Such an event may includereceiving a message such as “node failure detected” (e.g., from a DAGnode, or from a health management component of a provider network) or“available for service” (e.g., from a DAG node that has restarted aftera failure). In some embodiments the configuration manager itself may beresponsible for monitoring the health status of various DAG nodes, andthe triggering event may be a detection by the configuration managerthat one of the nodes has not responded in a timely fashion to somenumber of heartbeat messages or other health checks. In at least someembodiments, the DAG nodes may be responsible for reporting any apparentnode failures (e.g., when a connection is unexpectedly dropped, or whenno message is received from a neighbor node for a time period greaterthan a threshold) to the DCM. A DAG node may also be responsible fornotifying the DCM of impending changes (such as when the node isscheduled to go offline for maintenance) that may lead to DAGconfiguration changes in some embodiments. The DCM may determine whetherthe indicated configuration change (e.g., a removal of a failed node, orthe joining of a new node) is to be made effective (element 904) in thedepicted embodiment, e.g., based on a consensus protocol that may beimplemented among a plurality of nodes of a DCM cluster. For example, insome implementations, a determination by one DCM node that a DAG nodehas failed may have to be confirmed at one or more other nodes of thecluster (e.g., by reviewing heartbeat responses received from the DAGnode at other DCM nodes) before the node is removed from theconfiguration. In other implementations, the decision as to whether toapply a possible configuration change may be performed without utilizinga consensus-based protocol. A sequence number or logical timestampassociated with the DAG configuration change may be determined orgenerated in some embodiments, e.g., for inclusion inconfiguration-delta messages sent to other nodes of the DAG so that theconfiguration changes can be processed in the correct order at the DAGnodes.

Independently of how the configuration change is approved, in someembodiments a representation of the configuration change may have to bereplicated at multiple storage locations of the DCM before the change isconsidered complete (element 907). Saving information about theconfiguration change in multiple locations may be an important aspect ofthe DCM's functionality in embodiments in which the DCM is to serve asthe authoritative source of DAG configuration information. In at leastsome implementations, only the change to the configuration (rather than,for example, the entire configuration) may be replicated. After theconfiguration change information has been saved, a set of DAG nodes towhich corresponding configuration-delta messages (indicating thejust-implemented change to the configuration, not necessarily the wholeconfiguration of the DAG) are to be sent from the DCM may be identified(element 910). In some embodiments, all the DAG members (potentiallyincluding a node that is being removed from the DAG as part of theconfiguration change indicated in the configuration-delta message) maybe selected as destinations for the configuration-delta messages. In oneembodiment, only the nodes that are assumed to be current DAG membersmay be selected, e.g., the configuration-delta message may not be sentto a node if it is being removed or is known to have failed. In otherembodiments, some subset of the members may be selected as destinations,and that subset may be responsible for propagating the configurationchanges to the remaining nodes. In embodiments in which a subset ofmembers are selected as destinations, the DCM may have to keep track ofwhich changes have been propagated to which members at any given time.After the destination set of DAG nodes have been identified, respectiveconfiguration-delta messages may be sent to them asynchronously withrespect to each other, and without requesting any pause in statetransition message processing or state transition request processing(element 913). In at least some embodiments, the configuration-deltamessages may include the configuration sequence number associated withthe configuration change. In some implementations, a compositeconfiguration-delta message may indicate two or more changes (e.g., aremoval of a failed node and a joining of a replacement node).

FIG. 10 is a flow diagram illustrating aspects of operations that may beperformed at a member node of a replication DAG in response to receivinga configuration-delta message from a configuration manager, according toat least some embodiments. Upon receiving such a configuration-deltamessage comprising a configuration change sequence number from the DCM(element 1001), the recipient DAG node may determine whether it hasmissed any prior configuration-delta messages in the depictedembodiment, e.g., by comparing the newly-received sequence number withthe highest sequence number received previously. If the recipientdetermines that one or more configuration-delta messages have not yetbeen received (element 1004), it may send a configuration refreshrequest to the DCM (element 1007). Such a refresh request may result inthe DCM re-sending the missed configuration-delta message or messages,for example, or in sending a different type of message in which theentire current configuration of the DAG is indicated.

If missing configuration-delta messages are not detected (also inoperations corresponding to element 1004), the recipient node may storethe received configuration change information in a configuration changerepository in local storage. The accumulated messages in the repositorymay be used to update the recipient's view of the DAG configuration(element 1010). Updating the local view of the DAG configuration mayinclude, for example, determining one or more DAG nodes and/or edges ofthe replication pathway or pathways to be used for future outgoing andincoming state transition messages. As mentioned earlier, because of theasynchronous nature of message delivery and because different parts of anetwork may experience different delays, the sequence in whichconfiguration-delta messages are obtained at one DAG node may differfrom the sequence in which the same set of configuration-delta messagesare received at another node. Accordingly, the replication pathwaysidentified at two different nodes at a given point in time may differfrom each other. In the depicted embodiment, the recipient node may takefurther actions if either its immediate predecessor node on areplication path has changed, or if its immediate successor has changed.If neither the immediate successor nor the immediate predecessor nodechanges, the processing of the configuration-delta message may end afterthe configuration change information is stored at local storage of therecipient node (element 1027) in some embodiments.

An example of a scenario in which an immediate predecessor node ischanged with respect to a node C of a DAG is the change of a portion ofa replication path from A-to-B-to-C to A-to-C. If the updatedconfiguration involves a change to an immediate predecessor node of therecipient, and no messages have yet been received directly from the newimmediate predecessor node (as detected in element 1013), the recipientnode (node C in the current example) may establish a connection to thenew immediate predecessor (node A in the current example). In addition,in at least some embodiments, the recipient node (e.g., node C) may alsosend a request to the new immediate predecessor (e.g., node A) forretransmission of STMs with sequence numbers higher than the mostrecently-received sequence number at the recipient node (element 1017).If node C has a successor node, it may continue to transmit any pendingstate transition messages to such a successor node while node C waits toreceive the requested retransmissions from node A.

If the configuration-delta message indicates that the immediatesuccessor node of the recipient has changed, (e.g., when mode A receivesthe same example configuration-delta message discussed above, indicatingthat node B has left the DAG), and no message has yet been received fromthe new immediate successor node (element 1021), the recipient node mayestablish a connection to the new successor node. In the above example,node A may establish a connection to node C, its new immediatesuccessor. State transition messages may subsequently be transferred tothe new immediate successor (element 1024).

Coordinated Suspension of Replication DAG Nodes

For provider network operators, large scale failure events that cancause near-simultaneous outages of a large number of applicationspresent a significant challenge. Customers whose applications areaffected by sustained outages may lose faith in the ability of theprovider networks to provide the levels of service needed for criticalapplications. Although the probability of large scale failure events canbe lowered by intelligent infrastructure design and by implementingapplication architectures that can take advantage of high-availabilityfeatures of the infrastructure, it may be impossible to eliminate largescale failures entirely. Techniques that can allow distributedapplications to recover more quickly and cleanly from failures thataffect multiple resources may therefore be developed in at least someembodiments. In some environments in which replication DAGs of the typedescribed above are employed for distributed application statemanagement, a coordinated suspension protocol may be used to supportmore effective and efficient recovery from distributed failures. In oneembodiment, for example, in response to a detection of a failurescenario, some number of nodes of a DAG may be directed by theconfiguration manager to stop performing their normal application statetransition processing operations (e.g., receiving state transitionrequest messages, storing local copies of application state information,and transmitting state transition request messages along theirreplication pathway(s)). After suspending their operations, the nodesmay synchronize their local application state records with other DAGnodes in at least some embodiments, perform a clean shutdown andrestart. After a node restarts, it may report back to the configurationmanager that it is available for resumption of service, and awaitre-activation of the DAG by the configuration manager.

FIG. 11a-11h collectively illustrate an example sequence of operationsthat may be performed at a replication DAG during such a coordinatedsuspension procedure, according to at least some embodiments. Each nodein the illustrated DAG may store a respective set of commit records, inwhich each commit record includes (or indicates, e.g., via a pointer) acorresponding commit sequence number (CSN). From the perspective of thenode, the local commit record set may thus represent the state of anapplication being managed using the DAG. Records of approved (but notyet committed) state transitions may also be kept at some or all of thenodes, as described earlier. It is noted that although the coordinatedsuspension technique is described herein in the context of dynamicreplication DAGs in which the DCM transmits configuration-delta messagesas described above to keep the DAG nodes updated regarding DAGconfiguration changes, a similar approach may be employed for otherstate replication techniques in some embodiments. For example, thecoordinated suspension technique may also be used in an environment inwhich configuration changes to a group of replication nodes areimplemented using a stop-the-world reconfiguration interval during whichall the nodes are updated in a synchronized fashion, such that thereplication group becomes operational only after all the nodes have beenmade aware of the new configuration. Thus, dynamic replication DAGs mayrepresent just one example of multi-node state replication groups (SRGs)at which the coordinated suspension technique may be implemented indifferent embodiments. At least some such SRGs may have their ownconfiguration managers analogous to the DCMs described earlier, and mayhave some nodes designated as committer nodes and other nodes designatedas non-committer nodes.

A replication DAG comprising five nodes 1102A, 1102B, 1102C, 1102D and1102E is shown in FIG. 11a , together with a DCM 1180. In the depictedexample, committer node 1102E comprises a suspension trigger detector1106 which determines that a coordinated suspension procedure should beinitiated for the DAG. A number of different types of causes may lead tothe initiation of the suspension procedure in different embodiments. Forexample, the suspension procedure may be initiated (a) because somethreshold number of nodes may have failed (such as failures at nodes1102B and 1102D, indicated by the “X” symbols), (b) because the rate atwhich configuration-delta messages are being received at the committernode (or at some other node) exceeds a threshold, (c) because the rateat which network packets or connections are being dropped at some DAGnode or the DCM exceeds a threshold, and so on. The committer node 1102Ein the depicted embodiment sends a DAG suspension request 1150comprising the highest sequence number among the sequence numbersrepresented in the committer node's commit record set. This highestsequence number may be referred to as the highest committed sequencenumber (HCSN) 1108 herein, and may be used as a reference forsynchronizing commit record sets among the DAG nodes during one of thesteps of the suspension procedure as described below. In someembodiments, the initial determination that a suspension should beinitiated may be made at one of the non-committer nodes, or at the DCM1180 itself, and a particular commit sequence number (ideally but notnecessarily the HCSN) may be chosen as the target sequence number up towhich the nodes should update their commit record sets.

In response to receiving the suspension request, the DCM 1180 may savethe HCSN in persistent storage 1175, as shown in FIG. 11b . The DCM maythen send respective suspend commands 1152 to at least a subset of theDAG nodes, such as commands 1152A and 1152B to nodes 1102A and 1102Crespectively in the depicted example scenario. In some embodiments, theDCM 1180 may send suspend commands to all the DAG nodes that are membersof the DAG according to the latest DAG configuration saved at the DCM(including the nodes that may have failed, such as 1102B and 1102D). Thesuspend commands may include the HCSN 1108.

Upon receiving a suspend command, a DAG node may stop processing statetransition requests/messages, and may instead begin a process to verifythat its commit record set includes all the commit records up to andincluding the commit record corresponding to the HSCN. It may be thecase, for example, that node 1102A and node 1102C may not yet have beennotified by the committer node 1102E regarding one or more committedstate transitions with sequence numbers less than or equal to the HCSN.In such a scenario, as shown in FIG. 11c , node 1102A may send a commitrecords sync request 1172B to committer node 1102E (as indicated by thearrow labeled “1 a”) and node 1102C may send a similar commit recordssync request 1172B to node 1102E (as indicated by the arrow labeled “1b”). The commit records sync requests 1172 may respectively include anindication of which commit records are missing at the nodes from whichthe requests are sent—e.g., node 1102A may indicate that it already hascommit records with sequence numbers up to SN1, while node 1102C mayindicate that it is missing commit records with sequence numbers SN2,SN3, and SN4. The missing commit records 1174A and 1174B may then besent to the nodes 1102A and 1102C respectively by the committer node, asindicated by the arrows labeled “2 a” and “2 b”. Nodes 1102A and 1102Cmay then send respective synchronization confirmations 1176A and 1176Bto the DCM 1180, as indicated by the arrows labeled “3 a” and “3 b”. TheDCM 1180 may add nodes 1102A and 1102C to a list of up-to-date nodes1133 (i.e., nodes that have updated their commit record sets to matchthe commit record set of the committer node 1102E) maintained at theDCM's persistent storage 1175, as indicated by the arrow labeled “4”.

As shown in FIG. 11d , the nodes of the DAG may terminate execution andrestart themselves in the depicted embodiment. The failed nodes 1102Band 1102D may restart as part of recovery from their failures, forexample. As part of the coordinated suspension procedure, nodes 1102Aand 1102C may save their commit record sets (and/or additional metadatapertaining to the operations of the nodes) in local storage after theircommit record sets have been synchronized with that of the committernode, and then initiate a controlled restart. Node 1102E may wait forsome time interval after it has sent the suspension request 1150(allowing the committer node to respond to at least some sync requests1172), save any state metadata to local storage, and then initiate itsown controlled restart as part of the suspension procedure in thedepicted embodiment.

After the DAG nodes 1102A-1102E come back online, they may each send arespective “available for service” message to the DCM 1180 in someembodiments, as shown in FIG. 11e , and await re-activation instructionsto resume their application state transition processing operations. TheDCM may be able to tell (using its up-to-date nodes list 1133) that thecommit record sets of nodes 1102B and 1102D may not be up-to-date, andmay accordingly send respective synchronization commands 1194 to nodes1102B and 1102D, as shown in FIG. 11f . In at least some implementationsthe synchronization commands may indicate the HCSN 1108. In response tothe synchronization commands 1194, nodes 1102B and 1102D may each sendtheir own commit records sync requests 1172C and 1172D to nodes that areknown to be up-to-date, indicating which commit records are missing intheir respective commit record sets. For example, node 1102B may sendits sync request 1172C to node 1102A, while node 1102D may send its syncrequest to node 1102E. In some embodiments, the DCM may specify thedestination nodes to which the commit records sync requests should besent. In one embodiment, all the non-committer DAG nodes may have tosynchronize their commit record sets with the committer node. Nodes1102B and 1102D may receive their missing commit records 1174C and 1174Drespectively, so that eventually all the nodes have synchronized theircommit record sets up to the HCSN. In some implementations, nodes 1102Band 1102D may send a confirmation to the DCM 1180 indicating that theircommit record sets have been updated/synchronized. In at least oneembodiment, the DCM may play a somewhat more passive role with respectto those nodes that are not in its up-to-date nodes list than describedabove with respect to FIG. 11f . In such an embodiment, when a failednode (such as 1102B or 1102D) comes back online, it sends a message tothe DCM to determine whether the newly-online node is missing any commitrecords. The DCM may inform the node (e.g., by simply indicating theHCSN) that commit records with sequence numbers up to the HCSN arerequired for the node to become up-to-date. The node may then beresponsible for bringing itself up-to-date and reporting back to the DCMonce it has synchronized its commit records up to the HCSN. Thus, insuch an embodiment, the DCM may not necessarily send a synchronizationcommand 1194; instead, the newly-online nodes may take the initiative tosynchronize their commit record sets.

After confirming that at least a threshold number of the nodes haveupdated commit record sets, the DCM 1180 may determine the configurationof the post-restart DAG. In some cases, the same configuration that wasin use prior to the suspension may be re-used, while in otherembodiments a different configuration may be selected. For example, itmay be the case that the DAG is required to have a minimum of fournodes, so only four of the nodes 1102A-1102E may be selected initially.As shown in FIG. 11g , the DCM 1180 may send respective re-activationmessages to the selected set of nodes (all five nodes in the depictedexample), indicating the current configuration of the DAG. The DAG nodesmay then resume normal operations, as indicated by FIG. 11h . In someembodiments, at least some of the DAG nodes that did not fail (e.g.,1102A, 1102C and 1102E) may not necessarily restart themselves. Instead,after synchronizing their commit record sets, one or more of such nodesmay simply defer further state transition processing until they receivea re-activation command from the DCM in such embodiments.

FIG. 12 is a flow diagram illustrating aspects of operations that may beperformed at a committer node of an SRG such as a replication DAG duringa coordinated suspension procedure, according to at least someembodiments. As shown in element 1201, the committer node may determinethat a triggering criterion for a coordinated suspension of the SRG hasbeen met. A variety of different triggering conditions may lead to acoordinated suspension, including, for example, a detection by thecommitter node that the number of SRG nodes that remain responsive hasfallen below a threshold, or that the rate at which the SRG'sconfiguration changes are occurring exceeds a threshold. In some casesresource workload levels or error rates may trigger the suspension—e.g.,if the rate at which network packets are dropped exceeds a threshold, orif connections are being unexpectedly terminated at or above a maximumacceptable rate. In one embodiment, a non-committer node of the SRG, ora configuration manager such as the DCM, may initially detect a problemthat should lead to a controlled suspension, and may inform thecommitter node about the problem.

After determining that controlled suspension is to be initiated, thecommitter node may pause or stop its normal processing/replication ofstate transition messages, and save any outstanding as-yet-unsavedcommit records to local storage (element 1204) in the depictedembodiment. The committer node may then transmit a suspension request,including an indication of the HCSN (the highest-committed sequencenumber among the sequence numbers of transitions for which commitrecords have been stored by the committer node), to the SRG'sconfiguration manager (e.g., the DCM in the case of a replication DAG)(element 1207). The HCSN may serve as the target commit sequence numberup to which currently active nodes of the SRG are to synchronize theircommit record sets.

In at least some embodiments, after it sends the suspension request, thecommitter node may receive some number of commit record sync requestsfrom other SRG nodes (e.g., nodes that have determined that they do nothave a full set of commit records with sequence numbers up to the HCSN)(element 1210). In the depicted embodiment, the committer node respondto any such sync requests that are received during a configurable timewindow. The committer node may then optionally perform a clean shutdownand restart and send an available-for-service message to theconfiguration manager of the SRG (element 1213). In some embodiments,the clean shutdown and restart may be omitted, and the committer nodemay simply send an available-for service message, or the committer nodemay simply defer further state transition-related processing untilre-activation instructions are received from the configuration manager.Eventually, the committer node may receive a re-activation message fromthe configuration manager, indicating the current post-suspensionconfiguration of the DAG, and the committer node may then resume statetransition related processing (element 1216) as per the indicatedconfiguration. In some embodiments, it may be the case that in the new,post-suspension configuration, the committer node is no longer grantedthe role of committer; instead, it may be configured as an acceptornode, an intermediary node or a standby node, for example.

FIG. 13 is a flow diagram illustrating aspects of operations that may beperformed at a non-committer node of a state replication group such as areplication DAG during a coordinated suspension procedure, according toat least some embodiments. During normal operations, the non-committernode may store commit records in local storage at some point after thecorresponding transitions have been committed; as a result, the localcommit record set of the non-committer node may not necessarily be ascurrent as that of the committer node. As shown in element 1301, thenon-committer node may receive a suspend command from the configurationmanager, indicating an HCSN as the target sequence number to which thenon-committer node should synchronize its local commit record set.

Upon receiving the suspend command, the non-committer node may pause orstop processing new state transition messages. If some commit recordswith lower sequence numbers than the HCSN are missing from the localcommit record set, the non-committer node may send a commit record syncrequest for the missing records to the committer node (or to a differentnode indicated by the configuration manager as a source for missingcommit records) (element 1304). If its commit record set is alreadyup-to-date with respect to the HCSN, the non-committer node may not needto communicate with other nodes at this stage of the suspensionprocedure. After verifying that commit records with sequence numbers upto the HCSN are stored in local storage, the non-committer node may senda sync confirmation message to the configuration manager (element 1307)in the depicted embodiment. The non-committer node may then deferfurther application state transition processing until it is re-activatedby the configuration manager. Optionally, the non-committer node mayperform a clean shutdown and restart, and send an“available-for-service” message to the configuration manager afterrestarting (element 1310). In response to a re-activation message fromthe configuration manager, the non-committer node may update its view ofthe SRG configuration and resume application state transition processing(element 1313). In the post-suspension configuration, a different rolemay be granted to the non-committer node by the configuration manager insome cases—e.g., the non-committer node's role may be changed to acommitter node.

FIG. 14 is a flow diagram illustrating aspects of operations that may beperformed at a configuration manager of a state replication group suchas a replication DAG during a coordinated suspension procedure,according to at least some embodiments. As shown in element 1401, theconfiguration manager may receive a suspension request from a committernode of the SRG, indicating a highest-committed sequence number (HCSN)from among the sequence numbers of transitions whose commit records arestored at the committer node. In some embodiments, a consensus protocolmay be employed among the various nodes of the configuration managerbefore the decision to suspend the SRG operations is made final. Theconfiguration manager may store the HCSN in persistent storage (element1404) (e.g., at respective storage devices at several nodes of aconfiguration manager cluster), and send suspend commands indicating theHCSN to one or more other nodes of the SRG (element 1407). In someembodiments, the suspend commands may be sent to all the known membersof the SRG, including nodes that are assumed to have failed. Therecipient nodes of the SRG may each verify that their local commitrecord sets contain commit records corresponding to the HCSN (which mayin some cases require the recipient nodes to obtain missing commitrecords from the committer node as described above). After verifyingthat its commit record set is current with respect to the HCSN, arecipient of the suspend command may send the configuration manager async confirmation indicating that its commit record set is nowup-to-date. Accordingly, upon receiving such a confirmation from an SRGnode, the configuration manager may add that node to a list ofup-to-date nodes (element 1410).

In some embodiments, the configuration manager may wait to receiverespective messages from the SRG nodes indicating that they areavailable for service. Upon receiving such a message from a node (e.g.,after the node has completed a clean shutdown and restart, or after thenode has come back online after a failure), the configuration managermay determine whether the node is in the up-to-date nodes list or not.If the node from which the “available-for-service” indication isreceived is not known to be up-to-date with respect to commit records,the configuration manager may send indicate the HCSN to the node(element 1413), e.g., in an explicit synchronization command or inresponse to an implicit or explicit query from the node. Using the HCSNas the target sequence number up to which commit records are to beupdated, the node may then update its local commit record set bycommunicating with other nodes that are already up-to-date. In someembodiments, the configuration manager may include, in thesynchronization command, an indication of the source from which anout-of-date node should obtain missing commit records.

After the configuration manager has confirmed that a required minimumnumber of SRG nodes are (a) available for service and (b) up-to-datewith respect to application commit state, the configuration manager mayfinalize the initial post-suspension configuration of the SRG (element1416). The configuration manager may then send re-activation messagesindicating the configuration to the appropriate set of nodes that are inthe initial configuration (element 1419). In some embodiments, theinitial configuration information may be provided to the nodes as asequence of configuration-delta messages.

In at least some embodiments, the target sequence number selected forsynchronization (i.e., the sequence number up to which each of aplurality of nodes of the SRG is to update its local set of commitrecords) need not necessarily be the highest committed sequence number.For example, it may be the case that the highest committed sequencenumber at a committer node is SN1, and due to an urgent need to suspendthe SRG's operations as a result of a detection of a rapidly escalatinglarge-scale failure event, the SRG configuration manager may be willingto allow nodes to suspend their operations after updating their commitrecords to a smaller sequence number (SN1−k). In some implementations,the nodes of the SRG may synchronize their commit records to some lowersequence number before suspending/restarting, and may synchronize to thehighest-committed sequence number after the suspension—e.g., after thenodes restart and send “available-for-service” messages to theconfiguration manager. As noted earlier, in some embodiments thesuspension procedures may be initiated by non-committer nodes, or by theconfiguration manager itself.

Log-Based Optimistic Concurrency Control for Multiple-Data-StoreTransactions

In some embodiments, replication DAGs of the type described above may beused to implement optimistic concurrency control techniques using alogging service that enables support for transactions involving multipleindependent data stores. FIG. 15 illustrates an example systemenvironment comprising a persistent change log supporting transactionsthat may include writes to a plurality of data stores, according to atleast some embodiments. System 1500 shows a persistent change log 1510that may be instantiated using a logging service. One or more datastores 1530, such as data store 1530A (e.g., a NoSQL or non-relationaldatabase) and data store 1530B (e.g., a relational database) may beregistered at the logging service for transaction management in thedepicted embodiment. The terms “concurrency control”, “transactionmanagement”, and “update management” may be used as synonyms herein withrespect to the functionality provided by the logging service. Thelogging service may be considered one example of a plurality of storageservices that may be implemented at a provider network in someembodiments.

Clients 1532 may submit registration requests indicating the set of datasources for which they wish to use log-based transaction management fora particular application in some embodiments, e.g., via anadministrative or control-plane programmatic interface presented bylogging service manager 1501. The persistent change log 1510 may beinstantiated in response to such a registration request in someembodiments. In general, a given persistent change log instance may becreated for managing transactions for one or more underlying datastores—that is, in at least some deployments log-based transactionmanagement may be used for a single data store rather than for multipledata stores concurrently. The term “data store”, as used herein, mayrefer to an instance of any of a wide variety of persistent or ephemeraldata repositories and/or data consumers. For example, some data storesmay comprise persistent non-relational databases that may notnecessarily provide native support for multi-item transactions, whileother data stores may comprise persistent relational databases that maynatively support multi-item transactions. In some embodiments, anetwork-accessible storage service of a provider network that enablesits users to store unstructured data objects of arbitrary size,accessible via a web-services interface, may be registered as one of thedata stores. Other types of data stores may comprise in-memorydatabases, instances of a distributed cache, network-accessible blockstorage services, file system services, or materialized views. In atleast one embodiment, one or more of the data stores may includecomponents of a queueing service and/or a notification serviceimplemented at a provider network. Entities that consume committedwrites recorded by the logging service, e.g., to produce new dataartifacts, may represent another type of data store, and may be referredto generically as “data consumers” herein. Such data stores may, forexample, include a pre-computed query results manager (PQRM) (as in thecase of data store 1530C) responsible for generating results ofspecified queries on a specified set of data managed via the loggingservice (where the specified set of data may include objects stored atone or more different other data stores). In some embodiments, snapshotmanagers configured to generate point-in-time snapshots of some or allcommitted data managed via the logging service may represent anothercategory of data stores. Such log snapshots may be stored for a varietyof purposes in different embodiments, such as for backups or for offlineworkload analysis. The term “data consumers” may be used herein to referto data stores such as PQRMs and snapshot managers. At least some of thedata stores may have read interfaces 1531 that differ from those ofothers—e.g., data store (DS) read interface 1531A of data store 1530Amay comprise a different set of APIs, web-based interfaces, command-linetools or custom GUIs (graphical user interfaces) than DS read interface1531B or pre-computed query interface 1531C in the depicted embodiment.

In the depicted embodiment, logging service clients 1532 may constructtransaction requests locally, and then submit (or “offer”) thetransaction requests for approval and commit by the persistent changelog 1510. In one implementation, for example, a client-side library ofthe logging service may enable a client to initiate a candidatetransaction by issuing the logical equivalent of a “transaction-start”request. Within the candidate transaction, a client may perform somenumber of reads on a selected set of objects at data stores 1530,locally (e.g., in local memory) perform a proposed set of writesdirected at one or more data stores. The client may then submit thecandidate transaction by issuing the equivalent of a “transaction-end”request. The candidate transaction request 1516 may be received at aconflict detector 1505 associated with the persistent change log 1510via the log's write interface 1512 in the depicted embodiment. Ingeneral, in at least some embodiments, a given transaction request 1516may include one or more reads respectively from one or more data stores,and one or more proposed writes respectively directed to one or moredata stores, where the set of data stores that are read may or may notoverlap with the set of data stores being written. The reads may beperformed using the native DS read interfaces 1531 in some embodiments(although as described below, in some scenarios clients may also performread-only operations via the persistent change log 1510).

At least some of the writes indicated in a given transaction request maybe dependent on the results of one or more of the reads in someembodiments. For example, a requested transaction may involve readingone value V1 from a location L1 at a data store DS1, a second value V2from a second location L2 at a data store DS2, computing a functionF(V1, V2) and storing the result of the function at a location L3 atsome data store DS3. In some locking-based concurrency controlmechanisms, exclusive locks may have to be obtained on L1 and L2 toensure that the values V1 and V2 do not change before L3 is updated. Inthe optimistic concurrency control mechanism of the logging serviceillustrated in FIG. 15, no locks may have to be obtained. Instead, inthe depicted embodiment, the conflict detector 1505 may determine, basedat least in part on the contents of the transaction descriptor 1516 andon a set of committed transaction log records 1527 of persistent changelog 1510, whether the set of data items read in the requestedtransaction have been updated since they were read from their respectivedata stores. A sequence number based technique may be used to determinewhether such read-write conflicts exist in at least some embodiments, asdescribed below in further detail. If the conflict detector 1505determines that none of the data that was read during the transactionwas overwritten, the requested transaction may be accepted for commit,and such accepted-for-commit transactions 1514 may be submitted forreplication of corresponding log records at the persistent change log.The terms “approve” and “accept” may be used as synonyms herein withrespect to requested transactions that are not rejected. If some of theread data was updated since the corresponding reads occurred (or if aprobability that the data was updated is estimated by the conflictdetector to be greater than a threshold), the requested transaction 1516may instead be rejected or aborted in the depicted embodiment. This typeof approach to concurrency control may be deemed optimistic in thatdecisions as to whether to proceed with a set of writes of a transactionmay be made initially under the optimistic assumption that read-writeconflicts are unlikely. As a result, in scenarios in which read-writeconflicts are in fact infrequent, higher throughputs and lower responsetimes may be achieved than may be possible if more traditionallocking-based techniques are used.

In the case where a transaction is accepted for commit, contents of acommitted transaction log record may be replicated at some number ofnodes of a replication DAG associated with the persistent change log1510 (as described below in further detail with respect to FIG. 16) inthe depicted embodiment before the commit is considered successful. Ifthe requisite number of replicas is not created, the transaction may berejected or aborted in the depicted embodiment. The number of replicasrequired for a commit may vary for different applications or clients.Committed transaction log records may also be referred to herein as“commit records”. In some embodiments, the requesting client 1532 may benotified when the requested transaction is committed. In at least oneembodiment, the client 1532 may be informed when a transaction isrejected, so that, for example, a new transaction request may begenerated and submitted for the desired updates.

For each transaction that is committed, in at least some embodiments acommit sequence number (or some other identifier indicative of thecommitted state of the application) may be generated and stored (e.g.,as part of each of the replicas of the committed transaction log record)at the persistent change log 1532. Such a commit sequence number may,for example, be implemented as a counter or as a logical timestamp, asdiscussed above with respect to the sequence numbers used at replicationDAGs for state transitions. The commit sequence number may bedetermined, for example, by the conflict detector in some embodiments,or at a different component of the persistent change log (such as thecommitter node of the replication DAG being used) in other embodiments.In the depicted embodiment, after a given transaction is committed andits commit record is stored at the persistent change log, the writes ofthe transaction may be applied or propagated to one or more of the datastores 1530 to which they were directed (or, as in the case of the PQRM1530C, where the written data is to be consumed). In someimplementations, the writes may be pushed in an asynchronous fashion tothe targeted data stores 1530. Thus, in such implementations, there maybe some delay between the time at which the transaction is committed(i.e., when the required number of replicas of the commit record havebeen successfully stored) and the time at which the payload of aparticular write operation of the committed transaction reaches thecorresponding data store. In the embodiment shown in FIG. 15, respectiveasynchronous write appliers 1517 may be used to propagate some or all ofthe writes to relevant data stores. For example, write applier 1517A isconfigured to apply writes 1515A that are relevant to or data store1530A, write applier 1517B pushes writes relevant to data store 1530B,and write applier 1517C pushes writes that are to be consumed at datastore 1530C. In some implementations, the write appliers may comprisesubcomponents (e.g., threads or processes) of the persistent change log1510, while in other implementations, write appliers 1517 may beimplemented as entities external to the persistent change log. In someembodiments, a given write applier 1517 may be responsible forpropagating writes to more than one data store 1530, or a single datastore 1530 may receive writes from a plurality of write appliers 1517.In at least one implementation, a pull technique may be used topropagate written data to the data stores—e.g., one or more data stores1530 may submit requests for writes to the persistent change log 1510 orthe write appliers, instead of being provided written data at theinitiative of the write appliers. After the data written during atransaction is applied to the corresponding data stores, clients 1532may be able to read the updated data using the respective readinterfaces of the data stores. In some embodiments, at least one of thewrite appliers may be capable of performing synchronous writes (e.g.,either when explicitly directed to do so by the logging service, or forall the writes for which the applier is responsible). For example, aclient may wish to ensure that at least one write of a given transaction(such as a write directed to a “master” data store among the pluralityof data stores involved in the transaction) has been applied before theclient is informed that the transaction has been committed. The specificwrites to be performed synchronously may be indicated in the transactionrequest 1516 in some embodiments.

In some embodiments, as described below in further detail, a giventransaction request 1516 may include respective indicators of a read setof the transaction (i.e., information identifying the set of dataobjects read during the transaction), the write set of the transaction(i.e., information identifying the set of data objects that are to beupdated/written if the transaction is committed), the write payload(i.e., the set of data bytes that are to be stored for each write),and/or a conflict check delimiter (an indication of a subset of thecommitted transaction log records that should be examined toaccept/reject the transaction). Some or all of these constituentelements of a transaction request may be stored within the correspondingcommit record, together with the commit sequence number for thetransaction. In at least one embodiment, the persistent change log 1510may provide an identifier 1590 of the latest committed state of theapplication (such as the highest commit sequence number generated thusfar), e.g., in response to a query from a data store or a query from alogging service client. The write appliers may indicate the commitsequence numbers corresponding to the writes that they apply at the datastores in the depicted embodiment. Thus, at any given point in time, aclient 1532 may be able (e.g., by querying the data store) to determinethe commit sequence number corresponding to the most-recently-appliedwrite at a given data store 1530.

In at least some embodiments, during the generation of a transactionrequest (e.g., by a client library of the logging service), themost-recently-applied commit timestamps may be obtained from the datastores that are accessed during the transaction, and one or more of suchcommit sequence numbers may be indicated in the transaction request asthe conflict check delimiter. For example, consider a scenario in which,at the time that a particular client initiates a transaction thatincludes a read of a location L1 at a data store DS1, the commitsequence number corresponding to the most recently applied write at DS1is SN1. Assume further that in this example, the read set of thetransaction only comprises data of DS1. In such a scenario, SN1 may beincluded in the transaction request 1516. The conflict detector mayidentify commit records with sequence numbers greater than SN1 as theset of commit records to be examined for read-write conflicts for therequested transaction. If any of the write sets of the identified commitrecords overlaps with the read set of the requested transaction, thetransaction may be rejected/aborted; otherwise, the transaction may beapproved for commit in this example scenario.

In the depicted embodiment, the logging service may expose one or moreprogrammatic log read interfaces 1513 (e.g., APIs, web-pages,command-line utilities, GUIs, and the like) to enable clients 1532 toread log records directly. In other embodiments, such read APIs allowingdirect access to the change log 1510 may not be implemented. The abilityto directly access log records indicating specific transactions thathave been committed, and to determine the order in which they werecommitted, may enable new types of analyses to be performed in someembodiments than may be possible from accessing just the data storesdirectly (since at least some of the data stores may typically onlyallow readers to see the latest-applied versions of data objects, andnot the histories of data objects).

The optimistic concurrency control mechanism illustrated in FIG. 15 mayallow more complex types of atomic operations to be supported than mayhave been possible using the underlying data stores' concurrency controlmechanisms in at least some scenarios. For example, somehigh-performance non-relational data stores may only allow single-itemtransactions (i.e., writes may be permitted one at a time, but ifmultiple writes are submitted in a single batch update,atomicity/consistency guarantees may not be provided for the multiplewrites taken together). With the log-based approach described above, asingle transaction that encompasses writes to multiple locations of thenon-relational data store (and/or other data stores as well) may besupported with relative ease. A persistent change log 1510, togetherwith the associated conflict detector 1505, may be referred to as alog-based transaction manager herein. In some embodiments, the writeappliers 1517 may also be considered subcomponents of the transactionmanager.

As mentioned above, the persistent change log 1510 may be implementedusing the replication DAG described earlier in some embodiments. FIG. 16illustrates an example implementation of a persistent change log using areplication DAG 1640, according to at least some embodiments. In thedepicted embodiment, the application state transitions managed by theDAG correspond to transactions requested by log client 1660 as part ofan application that includes reads and writes directed to a set of oneor more data stores. The state of the application may be modeled as arespective set of transaction records 1672 stored in local storage atacceptor node 1610, intermediate node 1612, committer node 1614 andstandby node 1616, with a current replication path comprising nodes1610, 1612 and 1614. In some implementations, separate transactionrecords for approval (i.e., indicating that the requested transactionhas been approved for commit) and commit may be stored, while in otherembodiments, a single transaction record may be stored with a field thatindicates whether the transaction has been committed or not. A sequencenumber or logical timestamp may be stored as part of, or indicated by,at least some of the transaction records in the depicted embodiment.

The decision as to whether a requested transaction 1650 is to beapproved for commit may be made by a conflict detector implemented atthe acceptor node 1610 in the depicted embodiment, although in otherembodiments the conflict detector may be implemented outside thereplication DAG. A fault-tolerant log configuration manager 164 may sendconfiguration-delta messages asynchronously to the DAG nodes 1610, 1612,1614 and 1616, with each such message indicating a change to the DAGconfiguration rather than the entire configuration of the DAG, andwithout requiring the DAG nodes to pause processing the stream ofincoming transaction requests submitted by client 1660. Each DAG nodemay independently process or aggregate the configuration-delta messagesreceived to arrive at its respective view 1674 (e.g., view 1674A at node1610, view 1674B at node 1612, view 1674C at node 1614, and view 1674Dat node 1616) of the current DAG configuration. At least some of theviews 1674 may differ from those at other nodes at a given point intime; thus, under normal operating conditions, the different DAG nodesmay not need to synchronize their view of the DAG configuration witheach other. Messages 1652A and 1652B indicating approved (but not yetcommitted) transactions may be transmitted from acceptor node 1610 andintermediate node 1612 respectively along the replication pathway. Inthe depicted embodiment, committer node 1614 may transmit messages 1653indicating commits to the acceptor and intermediate nodes as well as tostandby node 1616. Asynchronous write appliers 1692, shown in theembodiment of FIG. 16 as entities outside the replication DAG, maypropagate writes from various committed transaction records to theappropriate data stores or data consumers. In other embodiments, thewrite appliers may be implemented within the replication DAG, e.g., asrespective processes running within the DAG nodes. In someimplementations, only a subset of the DAG nodes may be read by theappliers 1692 in order to propagate committed writes to theirdestination data sources or consumers. In other embodiments, as shown inFIG. 16, the appliers may read committed transaction records from any ofthe DAG nodes to push the contents of the write payloads as describedearlier.

Transaction Request Elements

FIG. 17 illustrates example component elements of a transaction requestdescriptor 1744 that may be submitted by a client 1732 of a loggingservice, according to at least some embodiments. As shown, transactiondescriptor 1744 may include conflict check delimiter 1702, read setdescriptor 1704, write set descriptor 1706, write payload(s) 1708, andoptional logical constraint descriptors 1710 in the depicted embodiment.In the example shown, logging service client 1732 comprises a clientlibrary 1756 which may be utilized to assemble the transaction requestdescriptor. In at least some embodiments, the client library mayautomatically record the read locations 1761A, 1761B, and 1761Crespectively within data stores 1730A, 1730B and 1730C from which datais read during the transaction, and/or the write location 1771 (of datastore 1730C in the depicted example) to which data is written. In someimplementations, the client library 1756 may also obtain, from each ofthe data sources 1730, a corresponding commit sequence number (CSN) ofthe most recent transaction whose writes have been applied at the datastore most recently. In one embodiment, such CSNs may be retrievedbefore any of the reads of the transaction are issued to thecorresponding data stores, for example. In another embodiment, the CSNsmay be retrieved from a given data store 1730 just before the first readthat is directed to that data store within the current transaction isissued.

In the depicted embodiment, the conflict check delimiter 1702 may bederived from a function to which the most-recently-applied CSNs areprovided as input. For example, in one implementation, the minimumsequence number among the CSNs obtained from all the data stores readduring the transaction may be used. In another implementation, a vectoror array comprising the CSNs from each of the data stores may beincluded as the conflict check delimiter 1702 of the transaction requestdescriptor. The conflict check delimiter 1702 may also be referred toherein as a committed state identifier (CSI), as it represents acommitted state of one or more data stores upon which the requestedtransaction depends. In some embodiments, a selected hash function maybe applied to each of the read locations 1761A, 1761B or 1761C to obtaina set of hash values to be included in read descriptor 1704. Similarly,a selected hash function (either the same function as was used for theread descriptor, or a different function, depending on theimplementation) may be applied to the location of the write(s) of atransaction to generate the write set descriptor 1706. In otherembodiments, hashing may not be used; instead, for example, an un-hashedlocation identifier may be used for each of the read and write setentries. The write payload 1708 may include a representation of the datathat is to be written for each of the writes included in thetransaction. Optional logical constraints 1710 may include signaturesused for duplicate detection/elimination and/or for sequencing specifiedtransactions before or after other transactions, as described below infurther detail. Some or all of the contents of the transaction requestdescriptor 1744 may be stored as part of the transaction state records(e.g., approved transaction records and/or committed transactionrecords) replicated at the persistent change log 1510 in someembodiments.

It is noted that the read and write locations from which the readdescriptors and write descriptors are generated may represent differentstorage granularities, or even different types of logical entities, indifferent embodiments or for different data stores. For example, for adata store comprising a non-relational database in which a particulardata object is represented by a combination of container name (e.g., atable name), a user name (indicating the container's owner), and someset of keys (e.g., a hash key and a range key), a read set may beobtained as a function of the tuple (container-ID, user-ID, hash key,range key). For a relational database, a tuple (table-ID, user-ID,row-ID) or (table-ID, user-ID) may be used.

In various embodiments, the transaction manager may be responsible,using the contents of a transaction request and the persistent changelog, for identifying conflicts between the reads indicated in thetransaction request and the writes indicated in the log. For relativelysimple read operations, generating a hash value based on the locationthat was read, and comparing that read location's hash value with thehash values of writes indicated in the change log may suffice fordetecting conflicts. For more complex read requests in some embodiments,using location-based hash values may not always suffice. For example,consider a scenario in which a read request R1 comprises the query“select product names from table T1 that begin with the letter ‘G’”, andthe original result set was “Good-product1”. If, by the time that atransaction request whose write W1 is dependent on R1's results isexamined for acceptance, the product name “Great-product2” was insertedinto the table, this would mean that the result set of R1 would havechanged if R1 were re-run at the time the transaction acceptancedecision is made, even though the location of the “Good-product1” dataobject may not have been modified and may therefore not be indicated thewrite records of the log. To handle read-write conflicts with respect tosuch read queries, or for read queries involving ranges of values (e.g.,“select the set of product names of products with prices between $10 and$20”), in some embodiments logical or predicate-based read setdescriptors may be used. The location-based read set indicatorsdescribed above may thus be considered just one example category ofresult set change detection metadata that may be used in variousembodiments for read-write conflict detection.

Read-Write Conflict Detection

FIG. 18 illustrates an example of read-write conflict detection at alog-based transaction manager, according to at least some embodiments.In the depicted example, transaction commit records (CRs) 1852 stored atpersistent change log 1810 are shown arranged in order of increasingcommit sequence numbers from the top to the bottom of the log. Thelatest or most recently committed transaction is represented by CR1852F, with commit sequence number (CSN) 1804F and write set descriptor(WSD) 1805F. Each of CRs 1852A, 1852B, 1852C, 1852D and 1852E comprise acorresponding CSN 1804 (e.g., CSNs 1804A-1804E respectively) and acorresponding WSD 1805 (e.g., WSDs 1805A-1805E).

As shown, transaction request descriptor 1844 includes a conflict checkdelimiter (or committed state identifier) 1842, a read set descriptor1846 and a write set descriptor 1848. (The write payload of therequested transaction is not shown). The conflict detector of thelog-based transaction management system may be required to identify aset of CRs of log 1810 that are to be checked for conflicts with theread set of the requested transaction. The conflict check delimiter 1842indicates a lower-bound CSN that may be used by the conflict detector toidentify the starting CR of set 1809 to be examined for read-writeconflicts with the requested transaction in the depicted embodiment, asindicated by the arrow labeled “Match”. Set 1809 may include all the CRsstarting with the matching sequence number up to the most recentcommitted transaction (CR 1852F) in some embodiments. If any of thewrites indicated by the CR set 1809 overlap with any of the readsindicated in the transaction request 1844, such a read-write conflictmay lead to a rejection of the requested transaction. A variety ofmechanisms may be used to check whether such an overlap exists indifferent embodiments. In one embodiment, for example, one or morehashing-based computations or probes may be used to determine whether aread represented in the read set descriptor 1846 conflicts with a writeindicated in the CR set 1809, thereby avoiding a sequential scan of theCR set. In some implementations, a sequential scan of CR set 1809 may beused, e.g., if the number of records in the CR set is below a threshold.If none of the writes indicated in CR set 1809 overlap with any of thereads of the requested transaction, the transaction may be accepted,since none of the data that were read during the preparation of thetransaction request can have changed since they were read. In at leastone embodiment, a transaction request descriptor may also indicate anupper bound on the sequence numbers of transaction records to be checkedfor conflicts—e.g., the conflict check delimiter may indicate both astarting point and an ending point within the set of CS 1852.

Methods for Optimistic Log-Based Concurrency Control

FIG. 19 is a flow diagram illustrating aspects of control-planeoperations that may be performed at a logging service, according to atleast some embodiments. At least some of the administrative orconfiguration-related operations shown may be performed by a loggingservice manager 1501 such as that illustrated in FIG. 15, e.g., inresponse to invocations of one or more administrative programmaticinterfaces implemented at the logging service. As shown in element 1901,one or more data stores may be registered for transaction management viaa logging service that implements an optimistic concurrency controlmechanism, e.g., using the read-write conflict detection approachdescribed above. Transaction management for a variety of types of datastores with respective distinct read interfaces may be implemented usinga log-based approach in different embodiments, including for exampleinstances of relational databases, non-relational databases, in-memorydatabases, provider network-implemented storage services, distributedcache components, pre-computed query results managers, snapshotmanagers, queueing services, notification services, and so on. In someembodiments, some or all of the underlying data stores managed using agiven log instance may not support at least some of the ACID properties(atomicity, consistency, isolation and durability) that are supported bysome traditional relational database systems.

The logging service may identify a set of hosts to be used forreplication DAG nodes of a persistent change log to be implemented forthe registered data stores (element 1904), e.g., with the help of aprovisioning service implemented at a provider network. One or morehosts may also be identified for a configuration manager for thereplication DAG—for example, as described earlier, a cluster of nodesutilizing a consensus-based protocol for implementing DAG configurationchanges may be used in some implementations. Replication nodes and theconfiguration manager may be instantiated at the selected hosts. Othercomponents of the log-based transaction management mechanism, includingthe conflict detector, one or more write appliers and an optional readinterface manager for the persistent change log may be configured(element 1907). The read interface manager for the log may beresponsible in some embodiments for responding to read requestssubmitted directly to the log (instead of being submitted to the readinterfaces of the registered data stores). The write appliers may beinstantiated, in one example implementation as respective processes orthreads that subscribe to notifications when transactions are committedat the log. The conflict detector may comprise a module that utilizesthe read interface of the log in some embodiments. Configuration of theconflict manager may include, for example, establishing the order inwhich read-write conflicts are identified versus constraint checkingoperations corresponding to de-duplication or sequencing, the manner inwhich responses to clients are provided (e.g., whether and how clientsare informed regarding transaction rejections/commits), and so on. Insome embodiments, conflict detectors, write appliers and/or log readinterface managers may be implemented in a multi-tenant fashion—e.g., agiven conflict detector, write applier or read interface manager mayprovide its services to a plurality of clients for whom respective loginstances have been established.

After the various components of the persistent change log have beenconfigured, the flow of transaction requests from clients may be enabled(element 1910), e.g., by providing the appropriate network addressesand/or credentials to the clients. In at least some embodiments, thecontrol-plane operations performed at the logging service may includetrimming or archiving portions of the stored transaction state records(element 1914). In some such embodiments, for example, when the amountof storage used for transaction records of a given persistent change logcrosses a threshold, some number of the oldest transaction records maybe copied to a different storage facility (such as a provider networkstorage service, or a slower set of storage devices than are used forthe recent set of transaction records). In another embodiment, theoldest transaction records may simply be discarded. In at least oneembodiment, other control-plane operations may be performed as needed,such as switching between one instance of a persistence change log andanother—e.g., when the first change log reaches a threshold populationof records.

FIG. 20 is a flow diagram illustrating aspects of operations that may beperformed at a logging service in response to a transaction requestreceived from a client, according to at least some embodiments. As shownin element 2001, a logging service's conflict detector may receive atransaction request descriptor of transaction T1, e.g., indicating aconflict check delimiter, a read set, and a write set comprising one ormore writes to respective locations at one or more data stores for whicha persistent change log has been established by the logging service. Theconflict check delimiter may indicate a committed state of one or moresource data stores from which the results of the reads of thetransaction were obtained, and may therefore serve as a committed stateidentifier (CSI). CSIs may also be referred to as “snapshot sequencenumbers” in some environments, as they may correspond to a point-in-timelogical snapshot of the source data stores. A set Si of transactionrecords stored at the persistent change log may be identified forchecking potential conflicts with the requested transaction (element2004), e.g., using the conflict check delimiter and the sequence numbersof the transaction records stored in the log. Such a set Si may include,for example, all the records of transactions that have commit sequencenumbers higher than a sequence number indicated in the conflict checkdelimiter in one embodiment.

If a read-write conflict is detected (element 2007), e.g., if the readset of the requested transaction overlaps at least partly with the writeset of one of the transactions of set S1, the transaction T1 may berejected or aborted (element 2022). In some embodiments, hash functionsmay be used to determine whether such overlaps exist—e.g., if the readset hashes to the same value as a write set, a conflict may be assumedto have occurred. In some implementations, an indication or notificationof the rejection may be provided to the client from which thetransaction request was received, enabling the client to retry thetransaction by generating and submitting another request descriptor. Ifa conflict is not detected (as also determined in element 2007), T1 maybe accepted for commit (element 2010). In the depicted embodiment,replication of T1's transaction record may be initiated to persistentstorage, e.g., at a plurality of replication DAG nodes of the log. Insome embodiments, an acceptance sequence number may be assigned to T1when it is accepted for commit, and may be stored together with contentsof at least some of the transaction request descriptor elements in eachreplica. In at least one embodiment, the acceptance sequence number mayserve as a commit sequence number if the transaction eventually getscommitted.

Depending on the data durability needs of the application whosetransactions are being managed, a threshold number of replicas may haveto be stored before the transaction T1's commit is complete. If asufficient number of replicas are saved (as determined in element 2013),the commit may be deemed successful, and the requesting client may benotified in some embodiments regarding the commit completion (element2014). If for some reason the number of replicas that can be saved topersistent storage is below the required threshold (as also detected inelement 2013), the transaction may be aborted/rejected (element 2022).After T1 commits, in the depicted embodiment the write operationsindicated in T1's write set may be applied to the corresponding datastores or data consumers, e.g., by asynchronous write appliers (element2016). In some embodiments, at least one of the write appliers may besynchronous—e.g., a client may be notified that the transaction has beencommitted only after such a synchronous write applier completes thesubset of the transaction's writes for which updates are to be appliedsynchronously. After the updates have been applied, the updated dataelements may be read in response to client read requests received viathe respective data stores' read interfaces (element 2019). In additionto the read interfaces supported by the various registered data stores,in at least some embodiments the persistent change log may itself bequeried directly for transaction record contents, e.g., via aprogrammatic query/read interface of the logging service. In someimplementations, reads directed to the log via such a logging serviceinterface may be able to see the results of write operations morequickly in some cases than reads directed to the data stores, since thedata stores may rely on asynchronous appliers to propagate the writesthat are already present in the log. In some embodiments, synchronousappliers may be used, which propagate writes to the data stores as soonas the transaction is committed at the log. In other embodiments, eachapplier may have a configurable time window within which writes have tobe propagated to the corresponding data store or consumer, so that itbecomes possible to adjust the maximum delay between a transactioncommit and the appearance of the transaction's modified data at the datastores.

FIG. 21 illustrates examples of transaction request descriptors that maybe used to achieve respective special-case consistency objectives,according to at least some embodiments. In one embodiment, clients ofthe logging service may wish to enforce “read-after-write” consistencysemantics, according to which a write becomes visible to all readers assoon as it is committed. To ensure read-after-write consistency, i.e.,to ensure that reads always “see” data immediately after it iscommitted, a client may wish to submit transaction requests even forread-only transactions (as well as for transactions that containwrites). Read-only transaction request descriptor (TRD) 2144, forexample, has a null write set 2106A and a null write payload 2108A, buthas a non-null conflict check delimiter 2102A and a non-null read setdescriptor 2104A. Upon receiving such a read-only transaction requestdescriptor, the conflict detector may check whether an overlap existsbetween the read set indicated in the request and the writes that havebeen committed with sequence numbers higher than the sequence numberindicated in the conflict-check delimiter. If a conflict is detected,the read-only transaction may be rejected, thus disallowing reads tolocations to which writes may have been committed after the conflictcheck delimiter was generated, even though the requested transactiondoes not include any writes dependent on those reads.

In at least some embodiments, write-only transaction requests may besubmitted to the logging service under certain circumstances. For someapplications, it may be the case that the client does not wish toenforce read-write consistency checks, at least during some time periodsor for some data stores. Instead, the client may wish to have somewrites accepted unconditionally for commit during such time periods.Accordingly, a transaction request descriptor 2145 that has a null readset 2104B and/or a null conflict check delimiter 2102B may be submitted,with a non-null write set descriptor 2106B and a non-null write payload2108B. Such write-only requests may be submitted, for example, when adata store or object is being initially populated, or if only one writerclient is known to be submitting requests during some time period.

As mentioned earlier, in some embodiments asynchronous write appliersmay be used to propagate contents of committed writes from thepersistent change log to various data stores or data consumers. As aresult of the asynchronous nature of the write propagation, it may bethe case at some points of time that a set of committed writes has notyet been propagated to their intended data stores. In at least oneembodiment, it may be possible to flush such un-applied writes usingwrite-only transactions. For example, if a particular write applier WA1is configured to have no more than N un-applied writes outstanding to agiven data store DS1, a client may submit a write-only transactionrequest descriptor such as TRD 2145 directed to a special write locationWL1 in DS1, where WL1 is used specifically or primarily for flushingoutstanding committed writes. In some cases, such a TRD may not need tohave any write payload at all (e.g., write payload 2108B may be set tonull). When such a write-apply-flushing transaction request is accepted,a new pending committed write may be added to the log and to WA1's queueof outstanding requests. As the length of the queue grows, WA1 may haveto start applying the earlier-committed writes in the queue to meet itsrequirement of no more than N un-applied writes. In some embodiments,such write-apply-flushing requests may be submitted periodically, e.g.,once every second, to ensure that committed writes do not remain pendingfor too long. When a write-apply-flushing transaction's committed writereaches the head of an applier's queue, in some implementations aphysical write need not be performed; instead, for example, the appliermay simply send the commit sequence number corresponding to thetransaction to the destination data store as an indicator of themost-recently “applied” write.

For some applications, clients may wish to enforce strict serialization,during at least for some time periods. That is, only one(write-containing) transaction may be allowed to proceed at a time,regardless of whether any conflicts exist between the data read duringthe transaction and writes that may have been committed since thetransaction preparation was initiated. In such a scenario, a client maysubmit a strict-serialization transaction request descriptor 2146 to thelogging service, with its read set descriptor 2104C indicating theentire contents of all the data sets used by the application. In oneimplementation in which a hash value is used as an indicator of thelocations read/written, and a bit-wise comparison with write set entriesis used to detect conflicts, for example, a hash value included in readset descriptor 2402C may be set to a sequence of “1”s (e.g.,“1111111111111111” for a 16-bit hash value). If any write-containingtransactions have been committed with CSNs greater than the conflictcheck delimiter 2102C of such a TRD 2146, the transaction correspondingto TRD 2146 may be rejected. Thus, the writes indicated by write setdescriptor 2106C and write payload 2108C would only be committed if noother write has been committed (regardless of the location of such awrite) in the conflict check interval indicated by the descriptor.

De-Duplication and Sequencing Constraints

In some embodiments, clients of the logging service may wish to ensurethat duplicate entries are not written to one or more data stores. Inone such embodiment, in addition to performing read-write conflictdetection as described above, the logging service may also have toenforce a de-duplication requirement indicated in the transactionrequest. FIG. 22 illustrates an example of enforcing a de-duplicationconstraint associated with a transaction request received at a log-basedtransaction manager, according to at least some embodiments. As shown,the transaction request descriptor 2244 comprises a read-write conflictcheck delimiter 2212, a read-set descriptor 2214, a write-set descriptor2216, and a logical constraint delimiter 2218. The write payload of TRD2244 is not shown in FIG. 22. The logical constraint descriptor 2218includes LC-type field 2219 indicating that it represents ade-duplication constraint, de-duplication check delimiter 2220, andexclusion signature(s) 2222 in the depicted embodiment.

In order to determine whether to accept the requested transaction, thelogging service may have to perform two types of checks in the depictedembodiment: one for detecting read-write conflicts, and one fordetecting duplicates. The commit records 2252 in the persistent changelog 2210 may each include respective commit sequence numbers (CSNs2204), write set descriptors (WSDs) 2205, and de-duplication signatures(DDSs) 2206 in the depicted embodiment. To determine whether aread-write conflict has occurred, the logging service may identify CRset 2209, starting at a sequence number corresponding to read-writeconflict check delimiter 2212 and ending with the most-recent commitrecord 2252F, whose write sets are to be evaluated for overlaps with therequested transaction's read set descriptor 2214. If a read-writeconflict is detected (i.e., if such an overlap exists), the requestedtransaction may be rejected as described earlier.

To determine whether the requested transaction's write(s) representduplicates, another CR set 2259 may be identified in the depictedembodiment starting at a sequence number corresponding to de-duplicationcheck delimiter 2220, and ending at the most recent commit record 2252F.For each of the commit records in CR set 2259, the logging service maycheck whether any of the de-duplication signatures stored in the commitrecord match the exclusion signature(s) 2222 of the requestedtransaction. A duplicate may be detected if such a match is found, andthe requested transaction may be rejected in such a scenario even if noread-write conflicts were detected. If duplication is not detected, andif no read-write conflicts are detected, the transaction may be acceptedfor commit.

In at least some embodiments, a de-duplication signature 2206 mayrepresent the data items written by the corresponding transaction in adifferent way (e.g., with a hash value generated using a different hashfunction, or with a hash value stored using more bits) than the writeset descriptors. Such different encodings of the write set may be usedfor de-duplication versus read-write conflict detection for any of anumber of reasons. For example, for some applications, clients may bemuch more concerned about detecting duplicates accurately than they areabout occasionally having to resubmit transactions as a result of afalse-positive read-write conflict detection. For such applications, theacceptable rate of errors in read-write conflict detection may thereforebe higher than the acceptable rate of duplicate-detection errors.Accordingly, in some implementations, cryptographic-strength hashfunctions whose output values take 128 or 256 bits may be used forde-duplication signatures, while simpler hash functions whose output isstored using 16 or 32 bits may be used for the write signatures includedin the WSDs. In some scenarios, de-duplication may be required for asmall subset of the data stores being used, while read-write conflictsmay have to be checked for a much larger set of transactions. In suchcases, storage and networking resource usage may be reduced by usingsmaller WDS signatures than de-duplication signatures in someembodiments. It may also be useful to logically separate the read-writeconflict detection mechanism from the de-duplication detection mechanisminstead of conflating the two for other reasons—e.g., to avoid confusionamong users of the logging service, to be able to support separatebilling for de-duplication, and so on.

In other embodiments, the write set descriptors may be used for bothread-write conflict detection and de-duplication purposes (e.g.,separate exclusion signatures may not be used). Similarly, in someembodiments, the same sequence number value may be used as a read-writeconflict check delimiter and a de-duplication check delimiter—i.e., thesets of commit records examined for read-write conflicts may also bechecked for duplicates. In at least one embodiment, de-duplication maybe performed by default, e.g., using the write-set descriptors, withoutthe need for inclusion of a logical constraint descriptor in thetransaction request descriptor.

For some applications, clients may be interested in enforcing a commitorder among specified sets of transactions—e.g., a client that submitsthree different transaction requests for transactions T1, T2 and T3respectively may wish to have T1 committed before T2, and T3 to becommitted only after T1 and T2 have both been committed. Such commitsequencing constraints may be enforced using a second type of logicalconstraint descriptor in some embodiments. FIG. 23 illustrates anexample of enforcing a sequencing constraint associated with atransaction request received at a log-based transaction manager,according to at least some embodiments. As shown, the transactionrequest descriptor 2344 comprises a read-write conflict check delimiter2312, a read-set descriptor 2314, a write-set descriptor 2316, and adifferent type of logical constraint delimiter 2318 than logicaldescriptor 2218 of FIG. 22. The write payload of TRD 2344 is not shownin FIG. 23. The logical constraint descriptor 2318 includes LC-typefield 2319 indicating that it represents a sequencing constraint, asequencing check delimiter 2220, and required sequencing signatures2322A and 2322B corresponding to transactions T1 and T2 respectively inthe depicted embodiment. The logical constraint descriptor 2318 may beincluded in TRD 2344 to ensure that the requested transaction iscommitted only if both transactions T1 and T2 (represented by sequencingsignatures 2322A and 2322B) have been committed earlier.

In order to determine whether to accept the requested transaction, thelogging service may once again have to perform two types of checks inthe example illustrated in FIG. 23: one for detecting read-writeconflicts, and one for ensuring that the transactions T1 and T2 havebeen committed. The commit records 2352 in the persistent change log2310 may each include respective commit sequence numbers (CSNs 2304),write set descriptors (WSDs) 2305, and sequencing signatures 2306 in thedepicted embodiment. To determine whether a read-write conflict hasoccurred, as before, the logging service may identify CR set 2309,starting at a sequence number corresponding to read-write conflict checkdelimiter 2312 and ending with the most-recent commit record 2352F,whose write sets are to be evaluated for overlaps with the requestedtransaction's read set descriptor 2314. If a read-write conflict isdetected (i.e., if such an overlap exists), the requested transactionmay be rejected.

To determine whether the requested transaction's sequencing constraintsare met, another CR set 2359 may be identified in the depictedembodiment starting at a sequence number corresponding to sequencingcheck delimiter 2320, and ending at the most recent commit record 2352F.The logging service may have to verify that respective commit recordswith sequencing signatures that match required signatures 2322A and2322B exist within CR set 2359. If at least one of the requiredsignatures 2322 is not found in CR set 2259, the sequencing constraintmay be violated and the requested transaction may be rejected, even ifno read-write conflicts were detected. If both sequencing signatures arefound in CR set 2359, and if no read-write conflicts are detected, thetransaction may be accepted for commit.

The sequencing signatures stored within the CRs 2352 (and in the TRD2344) may be generated using a variety of techniques in differentembodiments. In some embodiments, they may be generated from the writesets of the transactions; in other embodiments, sequencing signaturesmay be based at least in part on other factors. For example, theidentity of the requesting client may be encoded in the sequencingsignatures in addition to the write signatures in some embodiments, theclock time at which the transaction was requested may be encoded in thesequencing signatures, or an indication of the location from which thetransaction was requested may be encoded, and so on. Similarconsiderations as described above regarding the use of differenttechniques for representing sequencing signatures than write setsignatures may apply in some embodiments. Accordingly, in someembodiments, a different technique may be used to generate sequencingsignatures than is used for generating write set descriptor contents,even if both the sequencing signatures and the write set signatures arederived from the same underlying write locations. For example, adifferent hash function or a different hash value size may be used. Inother embodiments, however, the write set descriptors may be used forboth read-write conflict detection and sequencing enforcement purposes(e.g., separate sequencing signatures may not be used). Similarly, insome embodiments, the same sequence number value may be used as aread-write conflict check delimiter and a sequencing checkdelimiter—i.e., the sets of commit records examined for read-writeconflicts may also be checked for sequencing. In some cases arbitrarynumbers or strings unrelated to write sets may be used as sequencingsignatures. In at least one embodiment, a constraint descriptor may notinclude an LC-type field; instead, the type of a constraint may beindicated by the position of the constraint descriptor within thetransaction request. In some embodiments, a “required” flag may beassociated with sequencing signatures, and an “excluded” flag may beassociated with a de-duplication signature, instead of using LC-typefields, for example. As mentioned earlier in the context of read-writeconflict check delimiters, in some embodiments CSN upper bounds may alsobe specified within a transaction request descriptor to indicate therange of commit records that should be examined for constraint checking,instead of just specifying the CSN lower bound.

In some embodiments, more complex sequencing constraints may be enforcedthan are illustrated in FIG. 23. For example, instead of simplyrequesting the logging service to verify that both transactions T1 andT2 must have been committed (in any order) prior to the requestedtransaction's commit, a client may be able to request that T1 must havebeen committed prior to T2. Similarly, in some embodiments a client maybe able to request negative ordering requirements: e.g., that some setof transactions {T1, T2, Tk} should have been committed before therequested transaction in some specified order (or in any order), andalso that some other set of transactions {Tp, Ts} should not have beencommitted.

In FIG. 22 and FIG. 23, a single type of logical constraint wasindicated in the transaction requests shown. In some embodiments,clients may wish to enforce several different types of logicalconstraints on various transactions. FIG. 24 illustrates an example of atransaction request descriptor comprising multiple logical constraintdescriptors, according to at least some embodiments. One sequencingconstraint is to be applied, and one de-duplication constraint is to beapplied for the same requested transaction represented by transactiondescriptor 2444. In the depicted embodiment, the read and write setdescriptors comprise 32-bit (4-byte) hash values for each data item reador written. For example, respective 4-byte read hash signatures 2464Aand 2464B may represent two data item locations in the read setdescriptor 2404, and respective 4-byte write hash signatures 2465A and2465B may be included in write set descriptor 2406 to represent twolocations targeted for writes if the transaction is committed.Read-write conflict check delimiter 2402 is to be used to select thelower bound of a range of sequence numbers in the persistent change logwhose commit records are to be checked for read-write conflicts with therequested transaction.

Transaction request descriptor 2444 may also include a sequencingconstraint descriptor 2408A and a de-duplication constraint descriptor2408B in the depicted embodiment. Sequencing constraint descriptor 2408Amay include a constraint type field 2409A, a sequencing check delimiter2410, and one or more required sequencing signatures such as 2412A and2412B corresponding to transactions whose commits must have beencompleted for the requested transaction to be accepted. De-duplicationconstraint descriptor 2408B may include a constraint type field 2409B, adeduplication check delimiter 2420, and a deduplication exclusionsignature 2422.

As shown, in the depicted embodiment, the required sequencing signatures2412A, 2412B and the de-duplication signature 2422 may respectivelycomprise 128-bit (16-byte) hash signatures 2466A, 2466B and 2467. Thus,the logical constraint signatures may each occupy four times as manybits as are used per data item for read and write set signatures in thedepicted example, which may help reduce the number of hash collisionsfor the logical constraint-related comparisons relative to thecomparisons performed for read-write conflict detection. In someembodiments, a cryptographic hash function such as MD5 may be used forthe sequencing and/or the de-duplication signatures. The use ofcryptographic hash functions may help reduce the probability of errorsin evaluating logical constraints to near zero in at least some suchembodiments. Although a reasonably low rate of transaction rejectionsbased on false positive hash collisions (e.g., on a false positiveread-write conflict detection) may be acceptable, at least some clientsmay be much more concerned about avoiding the acceptance of atransaction due to a false positive hash collision (e.g., in the case ofcommit sequencing), and the use of cryptographic-strength hash functionsmay help to avoid such erroneous transaction acceptances. In someimplementations, clients may be able to select hash functions to be usedfor duplicate detection and/or for sequencing purposes. Different hashfunctions and/or hash value lengths may be used for de-duplicationsignatures, sequencing signatures and/or read or write signatures insome embodiments than shown in FIG. 24—for example, the de-duplicationand sequencing signatures may differ in size. In at least someembodiments, the addresses of data items read or written may be used forread/write set signatures, deduplication and/or sequencing signatures,e.g., instead of using hash values generated from the addresses. In oneembodiment, the de-duplication and/or write signatures may be derivedfrom the write payload in addition to, or instead of, from the locationsto which data is written.

Additional logical constraints may also be specified in the transactionrequest descriptor in some embodiments, such as data integrity/validityconstraints or commit-by deadline constraints. An example data integrityor validity constraint may require, for example, that a particular valueV1 may only be stored in a data store DS1 if a different value V2 isalready stored, either in DS1 or in some other data store. A datavalidity constraint may define acceptable ranges (either unconditional,or conditioned on the values stored in specified data store locations)for specified data types or data items to be stored. Commit-byconstraints may indicate deadlines by which a transaction's commit is tobe completed, with the intent that the transaction should be abandonedor aborted if the deadline is not met.

FIG. 25 is a flow diagram illustrating aspects of operations that may beperformed at a logging service in response to a transaction request thatindicates one or more logical constraints, according to at least someembodiments. In the depicted embodiment, a given transaction's commitrequirements may include concurrency control requirements (e.g., arequirement that no read-write conflicts of the kinds described aboveare found) as well as logical constraint requirements. Bothde-duplication and sequencing logical constraints may be supported for asingle transaction (other logical constraints may also be supported, butonly the operations pertaining to de-duplication and sequencing areshown in FIG. 25) in at least some embodiments. As shown in element2501, a transaction request descriptor that includes one or more logicalconstraint descriptors of a transaction T1 may be received at a conflictdetector associated with a particular persistent change log instance ofa logging service. For each logical descriptor, a corresponding checkdelimiter may be specified in the depicted embodiment, to be used toselect the set of commit records to be analyzed to determine whether thelogical constraint is met or violated. Respective sets of one or moresignatures may also be specified for each logical constraint. The readand write sets of the requested transaction may also be indicated,together with a read-write conflict check delimiter. As mentionedearlier, in some embodiments, the same delimiter may be used for one ormore logical constraints as that used for checking read-write conflicts.Also, in at least one embodiment, separate signatures may not berequired for logical constraints; instead, for example, the write setsignatures may be used as de-duplication and/or sequencing signatures.

Using the read-write conflict check delimiter, a first set of commitrecords CRS1 to be analyzed may be identified in the depictedembodiment. Such a set may, for example, comprise those commit recordswhose sequence numbers lie in a range starting at the read-writeconflict check delimiter, up to the sequence number of the mostrecently-stored commit record (or up to a different upper boundindicated in the transaction request). If a read-write conflict isdetected (element 2504) (e.g., if the write sets of any of the commitrecords of CRS1 overlaps with the read set of the requestedtransaction), the transaction may be rejected/aborted (element 2531).Checking for read-write conflicts may also be referred to herein asverifying that the requested transaction meets concurrency controlrequirements. In some embodiments, the client from which the transactionrequest was received may be notified that the transaction has beenaborted.

If a read-write conflict is not detected (also in operationscorresponding to element 2504), each of the logical constraintsindicated by the corresponding descriptors may be checked in sequence inthe depicted embodiment. The next logical constraint descriptor in thesequence may be examined, and a new commit record set CRS-k may beselected for constraint analysis based on the check delimiter associatedwith the constraint (element 2507). For example, CRS-k may include allthe commit records with sequence numbers in the range starting with thedelimiter and ending at the highest recorded commit sequence number (orup to a different upper bound indicated in the transaction request). Theanalysis to be performed may depend on the type of the logicalconstraint descriptor. If a de-duplication constraint is to be checked,and if a duplicate is found by comparing the de-duplication signaturesof CDR-k and the requested transaction (element 2510), the transactionmay also be rejected/aborted (element 2531). If the constraint is ade-duplication constraint and no duplicate is found (as also detected inelement 2510), and if more logical constraints remain to be analyzed,the next logical constraint descriptor may be examined and theoperations corresponding to elements 2507 onwards may be repeated forthe next logical descriptor.

If the constraint descriptor indicates a sequencing constraintindicating one or more required signatures of committed transactions,the CRS-k for the sequencing constraint may be examined to ensure thatthe required signatures have in fact been stored for transactions whosecommits have completed. If the commit records of the requiredtransactions are not found (as detected in element 2513), the requestedtransaction may also be aborted/rejected (element 2531). If the commitrecords of the required transactions are found (also in operationscorresponding to element 2513), the sequencing constraint processing maybe complete. As in the case of read-write conflict detection, logicalconstraint checking may also be performed using hash functions for thecomparisons in at least some embodiments, thus avoiding the overhead ofscanning the commit record sets. If any logical constraint descriptorsremain (element 2516), they may be examined in turn. If no logicalconstraint descriptors remain (as also detected in element 2516), thetransaction may be accepted for commit. A procedure to save thetransaction's commit records in persistent storage may be initiated inthe depicted embodiment (element 2519), e.g., at several nodes of areplication DAG. If the replication succeeds (e.g., if a sufficientnumber of copies of the commit record are stored successfully atrespective storage devices) (as detected in element 2522), thetransaction's commit may be considered complete. If for some reason therequired number of replicas is not stored, the transaction may still berejected/aborted (element 2531). In some embodiments, a notificationthat the transaction has been successfully committed may be transmittedto the requesting client (element 2525).

In some embodiments, operations to check more than one logicalconstraint may be performed in parallel instead. In one embodiment, anycombination of the read-write conflict check and the logical constraintchecks may be performed in parallel. In some embodiments, responsesregarding each of the logical constraints indicated may be provided tothe requesting client, even if one or more of the constraints are notmet. For example, in the case of a transaction request with ade-duplication constraint and a sequencing constraint, the sequencingconstraint may be checked even if the de-duplication constraint isn'tmet, and the results of the evaluation of both constraints may beprovided to the client. In some implementations, clients may be able toexplicitly request that a specified subset or all of the logicalconstraints of a given transaction request are to be checked.

Pricing Policies for Log-Coordinated Storage Groups

A set of data stores for which at least write-containing transactionsare collectively managed using a log-based transaction manager asdescribed above may be referred to as member data stores of alog-coordinated storage group (LCSG) herein. For example, an LCSG maycomprise a plurality of data store instances, such as one or moreinstances of a non-relational database, one or more instances of arelational database, one or more storage objects of a provider networkstorage service, an in-memory database instance, a queueing serviceimplementing persistent queues, a notification service, and the like.The particular log-based transaction manager instantiated for the datastore members may also be considered a part of the LCSG. In at leastsome embodiments, an LCSG may be able to allow users to request avariety of cross-data-store operations. For example, a single logicalwrite performed within a given transaction at an LCSG may eventually betranslated into (i.e., may result in) a plurality of physical updatesapplied at several different data stores. In this way, several differentviews of the same underlying change may be made accessible via therespective data access interfaces of the data stores.

Consider a scenario in which a storage system client wishes to have thedata payload of the same write request be made visible at a databasesystem instance for persistence and data durability, an in-memorydistributed cache instance for low-latency access to the results of thewrite request, a data warehousing service for offline analysis, and anarchival storage service for long-term record retention. In oneembodiment, the client may construct a transaction that explicitlyindicates each of the four data stores as destinations for a givenlogical change to the application data. In another embodiment, inaddition to or instead of supporting cross-data-store transactions, thelogging service at which the LCSG is instantiated may support automatedcross-data-store transformations that do not require all the differentwrite targets to be explicitly specified within a given transactionrequest. Instead, e.g., in response to a configuration request or duringLCSG setup, the client may be able to indicate that for any given writedirected to the database instance, a corresponding representation is tobe automatically propagated to the in-memory cache, the data warehousingservice, and the archival storage service. Transformations in bothdirections between a given pair of data stores may be supported in someembodiments. For example, if a client application performs a writedirectly to a database instance, the results of the write may be addedautomatically by the logging service to the in-memory cache in theappropriate format expected by the in-memory cache, and if a clientapplication performs a different write directly to the in-memory cache,the results of that different write may be propagated automatically tothe database instance in the format expected by the database instance.

The logging service may implement several different pricing policies foroperations performed at an LCSG in some embodiments, at least some ofwhich may be based on the mix of operation types performed on behalf ofthe client (e.g., how many cross-data-store transformations and/ortransactions are performed during a time interval, as opposed to thenumber of operations that involved writes to a single data store). Thebilling amounts charged to an LCSG customer for a given billing periodmay vary based on a number of factors as described below, and on thepricing policy or policies selected for or by the customer. At leastsome of the pricing policies described below may be used in combinationwith each other for a given client—e.g., tiered pricing may be appliedfor both provisioned throughput and best effort resource allocationmodes, and respective provisioned-throughput pricing policies may beapplied for each data store of an LCSG.

In at least one embodiment, the number of different data stores includedwithin a given LCSG, the types of data stores included, and/or thenumber of cross-data-store operations performed on behalf of a client(e.g., operations or transactions involving generating a secondrepresentation of a write that is originally targeted to a particulardata store, at a different data store) may influence the billingamounts. For example, in accordance with one pricing policy,establishing an LCSG with eight data stores may cost more thanestablishing an LCSG with four data stores, assuming other factors suchas overall workload levels and/or data set sizes are identical. Inaccordance with other example pricing policies, an LCSG with fourrelational database instances supporting a particular workload level maycost more than an LCSG that comprises four in-memory database instancessupporting the same workload level. A client may be billed a particularamount per cross-data-store operation performed in some embodiments. Inone embodiment, the cost of a cross-data-store operation may also varybased on the type of data stores involved—e.g., an operation in which awrite initially directed to a relational database is translated into anadditional write at an in-memory database may cost a different amountthan an operation in which a write initially directed to anon-relational database is translated into another write at thein-memory database. The direction of write propagation may alsoinfluence the price of an operation in some embodiments—e.g., atranslation of a write from data store DS1 to DS2 may cost a differentamount than a translation of a write from DS2 to DS1.

In some embodiments, resources (such as compute servers, storagedevices, network bandwidth, memory and the like) may be allocated at aprovider network for use by an LCSG in one of several modes. In aprovisioned throughput mode of resource allocation, a client of thelogging service may indicate a target throughput rate (e.g., 100transaction per second) for a particular data store registered as amember of an LCSG, and the logging service may reserve sufficientresources such that the requested throughput can be sustained (at leastunder normal operating conditions, e.g., in the absence of failures).According to a pricing policy based on the provisioned-throughput mode,the client may be billed for the target throughput rate even if theactual workload submitted by the client happens to be below the targetduring a given billing period. Different provisioned throughputs may berequested by a client for various data stores of a given LCSG in someembodiments. According to some embodiments, the billing rate forprovisioned throughput may differ from one data store to another—e.g.,the rate for a provisioned throughput of 100 transactions/second for anon-relational database may differ from the rate for provisionedthroughput of 100 transactions per second for a relational database thatis a member of the same LCSG.

In at least some embodiments, in a different mode of resource allocationcalled best-effort mode, the logging service may not necessarily reserveor dedicate resources corresponding to a specified target throughput ofthe client. Instead, for example, resources from a shared pool or poolsmay be assigned to the client's LCSG. As the client's workload levelfluctuates, the logging service may make best-effort adjustments to theset of resources assigned to the client, based on the available capacityin the shared pool, for example. Pricing policies for best-effortresource allocation mode may result in different billing rates for thesame workload level than pricing policies for provisioned throughputresource allocation mode in at least some embodiments. As in the case ofprovisioned throughput, different billing rates may apply to differentdata stores for best-effort resource allocation in some embodiments.

According to at least one embodiment, a tiered throughput-based pricingmodel may be implemented. For example, a different billing rate B1(e.g., per transaction) may be charged if a client submits between 0 and1000 transactions/second than a billing rate B2 for transaction ratesbetween 1000 and 2000 transactions/second, and so on. Similar tier-basedpricing may also apply to bandwidth usage in some embodiments—e.g., adifferent billing rate per gigabyte of data transferred may be chargedif the total number of gigabytes transferred is between 0 and 10 GB/daythan if the total number of gigabytes transferred is between 10 and 20GB/day. In some embodiments, billing amounts may vary based at least inpart on the levels of high availability, data durability, latencyrequired by the LCSG clients with respect to the persistent change logsbeing used and/or with respect to the member data stores of the LCSG. Inat least one embodiment, LCSGs may be implemented at a storage servicethat natively supports a specified set of data store types, but alsoallows custom extensions to be added—e.g., for transformations between adata store type natively supported by the service and a different datastore type for which support is not provided natively. In some suchembodiments, a billing rate that applies to use of a given extension maydiffer from a billing rate used for natively-supported data store types.

In one implementation in which the various data stores of an LCSG areeach implemented via a respective service of a provider network thateach implement their own pricing policies, a client may be billedseparately for the use of those provider network services and for theuse of the LCSG. For example, the billing amounts for reads directed toa database instance of an LCSG may be computed in accordance with apricing policy of a database service, while billing for LCSGtransactions and cross-data-store transformation operations may bedetermined in accordance with an LCSG pricing policy.

In at least one embodiment, one or more programmatic interfaces (such asweb pages, APIs and the like) may be implemented to enable clients ofthe logging service to view alternative pricing policies and/or toselect specific pricing policies based on their preferences andrequirements. Workload-related metrics such as overall requestedtransaction and/or read rates, the numbers of cross-data-store andsingle-data-store operations performed, network bandwidth used, and thelike may be collected from the resources allocated for a customer'sLCSG. In at least some embodiments, part of the billing-related workperformed by the control plane of the logging service implementing theLCSGs may include classifying workload records into one subsetindicating cross-data-store operations versus a different subsetindicating single-data-store operations. For example, write records forboth types of operations (single-data-store versus cross-data-store) maybe stored in the same log at a given data store, and a workload analyzercontrol plane component may have to examine the contents of a writerecord to determine whether it represents a cross-data-store write or asingle-data-store write. In one implementation, a set of distributedmonitoring agents of a provider network being utilized for the LCSG maybe used for metrics collection. Depending on the pricing policy selectedfor an LCSG and on the metrics collected, a billing amount for aparticular billing period may be determined and indicated to a client.

FIG. 26 illustrates an example system environment in which respectivepricing policies may be implemented for respective log-coordinatedstorage groups (LCSGs), according to at least some embodiments. Asshown, system 2600 comprises two LCSGs, 2605A and 2605B. LCSG 2605Aincludes two data stores, 2630A and 2630B, while LCSG 2605B comprisesfour data stores 2630C, 2630D, 2630E and 2630F. Log-based transactionmanager (LTM) 2602A, comprising a conflict detector 2615A, persistentchange log 2601A, and a set of write appliers 2617A, is configured tohandle transaction request comprising writes directed by clients to thedata stores 2630A and 2630B. Similarly, LTM 2602B, comprising conflictdetector 2615B, persistent change log 2601B, and a set of write appliers2617B, is configured for managing writes directed by clients to datastores 2630C-2630F. The persistent change logs 2601 may also be referredto as write logs herein.

The control plane 2649 of a logging service or storage service at whichthe LCSGs are implemented may comprises a plurality of componentsresponsible for configuration and administration tasks, including forexample managing LCSG membership information, mappings between clientaccounts and service resources assigned to the accounts, keeping trackof pricing/billing policies in use for various LCSGs, and so on. Abilling manager 2651 may be responsible, for example, for generatingclient billing amounts based on one or more pricing policy options forrequests directed towards the LCSGs 2605A and 2605B in the depictedembodiment. The set of available pricing policies may be indicated toactual or potential customers of the service that implements the LCSGsvia one or more programmatic interfaces, such as web pages, APIs,command-line tools or custom GUIs, in the depicted embodiment. Customersmay also indicate the particular pricing policies to be applied to theirLCSGs via such programmatic interfaces in at least some embodiments,e.g., at the time that they register various data stores 2630 as LCSGmembers, or via pricing policy change requests submitted at some pointafter the LCSGs are set up. In the depicted embodiment, pricing policy2644A has been identified for LCSG 2605A, while a different pricingpolicy 2644B has been selected for LCSG 2605B. Each pricing policy mayindicate, for example, the billing rates to be used for variousdifferent operation types and/or resource usage units during at least aspecified billing period. The billing amounts (e.g., BA1 or BA2) that acustomer is charged for a given billing period may be determined by thebilling manager 2651 based on the pricing policy or policies in effectfor their LCSGs during the billing period and on an analysis of variousmetrics that are collected during the billing period.

Metrics collectors 2655A may be responsible for monitoring variousresources, such as the servers and devices used for the data stores2630A and/or the LTMs 2602, and providing an indication of the collectedmetrics to the billing manager 2651. In embodiments in which the LCSGsare implemented within provider networks, e.g., using services of theprovider network such as a computing service, a storage service and thelike, a pre-existing metrics collection infrastructure may be availablefor some or all of the services, from which at least some of the metricsneeded for generating billing amounts may be obtained by the billingmanager. In one embodiment, the control plane 2649 may includerespective components for various pricing/billing related tasks—e.g., amembership manager that is responsible for identifying the members ofeach LCSG, a metrics analyzer for classifying collected workload metricsinto per-client and/or per-operation-type subgroups, and a billgenerator that produces the billing amounts for various clients based onselected pricing policies and workload metrics.

A number of different factors may be taken into account in a givenpricing policy 2644 applied to an LCSG 2605, such as the number and/ortypes of data stores 2630 that are members of the LCSG, the mix ofoperations (single-data-store writes versus cross-data-store writes),the resource allocation model used (e.g., provisioned throughput versusbest effort), the requested transaction rates, and so on. FIG. 27illustrates examples of single-data-store and cross-data-store writeoperations, according to at least some embodiments. LCSG 2705 in thedepicted embodiment comprises six member data stores: NoSQL DB instance2730A, key-value in-memory DB 2730B, distributed cache instance 2730C,relational DB instance 2730D, storage service object 2730E and archivalservice object 2730F. As illustrated, the member data stores of a givenLCSG may implement very different data models (e.g., relational versusnon-relational, structured records versus unstructured data objects, andso on) and different read interfaces and data formats may therefore beused at the member data stores in at least some embodiments.

Two types of write operations are illustrated in FIG. 27—writes that areexplicitly included in requested transactions by clients, and writesthat the logging service is configured to perform automatically (e.g.,as a consequence or side-effect of the explicitly requested writes). Atransaction request 2702A indicates that a write payload W1 is to bedirected to NoSQL DB instance 2730A, and also to storage service object2730E. Accordingly, a representation W1-A of write payload W1 is storedin NoSQL DB instance 2730A, and another representation W1-B of the samewrite payload is stored in storage service object 2730E. Similarly,transaction request 2702B also includes a request for a cross-data-storewrite of payload W2. Accordingly, a first representation W2-A of thewrite payload W2 is stored at relational DB instance 2730D, while asecond representation W2-B of the write payload W2 is stored atdistributed cache instance 2730C. Transaction request 27002C comprises asingle-data-store write. Representation W3-A of transaction request2702C's write payload W3 is accordingly stored at the NoSQL DB instance2730A. In at least some embodiments, the billing rates for transactionswith single-data-store writes may be different from the billing ratesfor cross-data-store write transactions. In at least someimplementations, a baseline billing rate may be charged per transaction,and additional billing amounts may be charged based on the number anddestination data store types of writes included in the transaction.

In addition to the writes explicitly indicated in the requestedtransactions, LCSG 2705 may also support automated transformationsand/or copying of data from one member data store to another. Twoexamples of such cross-data-store transformations are shown in FIG. 27.In the first example, a third representation W1-C of write payload W1 isautomatically generated from representation W1-B of storage serviceobject 2730E and stored in key-value in-memory database 2730B. In thesecond example, using W2-A as the source, a third representation W2-C ofwrite payload W2 is stored at archival service object 2730F. In at leastone implementation, respective write appliers may be set up for eachpair of source and destination data stores between which such automatedcross-data-store transformation operations are to be performed. Forexample, a particular write applier may be registered as a listener thatis to be notified when a write (such as W1-B) is applied to storageservice object 2730E, so that a corresponding write (such as W1-C) maybe performed at key-value in-memory database 2730B. In accordance withthe pricing policy in place for LCSG 2705, respective billing rates maybe set for each type of automated cross-data-store transformations inthe depicted embodiment. The billing rate may be based on variousfactors in different embodiments, such as the specific source anddestination data store types, the acceptable delay between the time thata particular write is applied to the source data store and thecorresponding representation is applied to the destination data store,and so on. Thus, for example, a billing rate BR1 may be used forgenerating, within archival storage service 2730F (the destination datastore) a different representation of an object originally written inrelational DB instance 2730D (the source data store), while a differentbilling rate BR2 may be used for generating a different representationof the same object within a different destination data store such asdistributed cache instance 2730C. For a given pair of data stores, thedirection of the cross-data-store transformation operation may influencethe billing rate in at least some embodiments.

FIG. 28 illustrates examples of factors that may be considered whendetermining pricing policies for log-coordinated storage groups,according to at least some embodiments. The number and types of datastores 2802 may influence several aspects of the pricing in someembodiments, including an initial up-front fee that clients may berequired to pay, as well as ongoing usage-based fees. For example, toset up an LCSG with four instances of a non-relational database, thebilling amount may differ from that for setting up an LCSG with oneinstance each of the non-relational database, a relational database, adistributed cache instance, and an archive instance at an archivalservice. The number of data stores in an LCSG may also represent thenumber of possible client-accessible views of the same underlying data.

The workload operation type mix 2804 may influence billing amounts in atleast some embodiments—e.g., as discussed above, cross-data-storeoperations may have a different cost than single-data-store operations.In some embodiments, the mix of reads and writes in a customer'sworkload could also affect the billing amount—e.g., a read may ingeneral cost less than a write. As described above with respect to FIG.15, in at least some embodiments a log read interface may enable clientsto issue reads directly to the persistent log of the LCSG, and aper-read cost for using such an interface may differ from the per-readcosts of using the data stores' interfaces. In some implementations inwhich reads to the data stores are handled by respective services of theprovider network (i.e., not by the logging service per se), the billingfor reads that use the data stores' native read interfaces may behandled separately from the billing associated with the use of thelogging service.

Pricing policies for the use of the LCSG may differ based on theresource allocation mode 2806 in some embodiments. The logging servicemay have to reserve or dedicate resources for a client inprovisioned-throughput mode to ensure that sufficient capacity remainsavailable for the client's specified throughput level. In contrast, forfulfilling client requests in best-effort resource allocation mode,shared resources may be used, which may enable higher utilization levelsof the logging service resources on average than for provisionedthroughput mode. Thus, in at least some embodiments, clients may becharged a different amount for the same actual transaction rate whenprovisioned-throughput mode is used than when best-effort mode is used.Request rate tiers 2808 may be defined for pricing policies in someembodiments. In accordance with tier-based pricing, the billing rate fora given transaction may differ depending on whether the client issuesbetween 0 and 1000 transaction requests per second, or whether theclient issues between 1000 and 2000 transactions per second. In at leastsome embodiments, the network bandwidth usage 2810 for a client'sworkload may influence the pricing policy. Depending on the nature ofthe transactions, a particular number N1 of transaction requests mayresult in X gigabytes of traffic for a first client, while N1transactions may result in Y gigabytes of traffic for another client (oreven for the first client during a different time interval). Since atleast some of the resource usage incurred by the logging service mayvary in proportion with the network bandwidth, some pricing policies ofthe logging service may be based at least in part on measured bandwidthusage. In various embodiments, the monitoring infrastructure (e.g.,metrics collectors 2655A) used by the logging service may use a varietyof techniques to assign bandwidth usage to different clients—e.g., suchassignments may be based on client IP addresses incorporated withinnetwork packet headers, client identifiers incorporated within packetheaders or bodies, and so on.

In at least some embodiments, pricing policies may be defined and/orselected based on latency requirements 2812, availability requirements2814, and/or data durability requirements 2816. For example, oneclient's application set may have a requirement for most transactions tobe accepted within 2 seconds of the corresponding transaction requestsbeing submitted, and such a client may be willing to pay a higher rateper transaction as long as at least 95% of the submitted transactionsare accepted within 2 seconds. Pricing policies based on such latencypercentile measures or average latency may therefore be supported by thelogging service in such embodiments. Different clients and/or clientapplications may have different high availability requirements 2814 forthe logging service (e.g., whether various components of the LCSG needto be online and responsive 99.99% of the time or 99.9999% of the time)in some embodiments, which may affect the pricing policies selected.Requirements for data durability 2816 (e.g., the maximum acceptable dataloss rate for log records) may also influence pricing in at least oneembodiment.

The logging service may natively support a number of different datastore types, such as proprietary databases or storage servicesimplemented at the provider network, popular open-source databases,caching services, and the like. In addition, in at least someembodiments, the logging service may be extensible by third parties orclients. In such an embodiment, a set of extensibility interfaces may beexposed, allowing organizations or individuals other than the operatorof the logging service to add support for log-based transactionmanagement for new data store types. Example extensions could includewrite appliers for various data stores not supported natively by thelogging service, or data transformers that allow such data stores toserve as sources or destinations of automated cross-data-storetransformations of the kinds illustrated in FIG. 27. In at least someembodiments, pricing policies for LCSGs may take the use of suchextensions into account—e.g., different charges may apply fortransactions that use the extensions than apply for transactions thatuse natively-supported data stores.

It is noted that in various embodiments, several (or all) of the factorsillustrated in FIG. 27 may be combined to identify a specific pricingpolicy to be used for a given LCSG for a given customer. For example,tiered pricing and/or bandwidth-based pricing may be applied incombination with either provisioned-throughput or best-effort resourceallocation modes in some embodiments. Similarly, the number and types ofdata stores included in the LCSG may influence billing amounts incombination with the workload operation mix, throughput tiers,latency-based pricing and the like in various embodiments.

In at least some embodiments, clients of the logging service may begiven the opportunity to select pricing policies from among severaloptions. FIG. 29 illustrates an example web-based interface that may beused to indicate pricing policy options to a user of a serviceimplementing log-coordinated storage groups, according to at least someembodiments. As shown, web page 2901 comprises a message area 2904 and anumber of form fields that may be used by a logging service user toexperiment with different pricing policy components and select thespecific set of pricing policy elements that best suits the user'srequirements and budget.

As indicated in message area 2904, the costs of using the LCSG in thedepicted embodiment may depend on the number and types of data storeswhose transactions are to be managed using the logging service. Usingelements 2907, the user may indicate how many different types of datastores are to be included in the LCSG for which the pricing is to beestimated or determined using web page 2901. For example, the client mayselect zero or more instances of a NoSQL database, zero or moreinstances of a relational database, zero or more instances of anin-memory database, and/or zero or more instances of other types of datastores. For several of the form fields shown on page 2901 including thedata store count fields, the logging service may indicate default values(such as a default value of 1 for the number of No SQL databaseinstances). In some embodiments, as the user fills in values in variousform fields, data in other elements of web page 2901 may be updatedinstantaneously or near-instantaneously. For example, if the userchanges the number of NoSQL database instances from 1 to 2, the effectof such a change on the total monthly billing amount 2925 may beindicated in real time.

Using form field 2910, the user may indicate a preference for a resourceallocation mode (e.g., provisioned-throughput versus best-effort) in thedepicted embodiment. A tiered pricing model may be used both forsingle-data-store requests and for cross-data-store request in theexample scenario of FIG. 29. For each data store type, the expectedrequest rate for writes (e.g., in writes per second) may be indicatedusing form fields 2913. The expected request rate for cross-data-storewrites (between a given source data store type and a given destinationdata store type) may be indicated using form field 2916. Expectedrequest rates for cross-data-store transformations between other sourceand destination pairs may be indicated as well, e.g., by clicking on thelink shown in field 2916 and indicating the sources, destinations, andrates. For one or more fields such as the fields for write requestrates, web page 2901 may provide drop-down menus with a discrete set ofoptions (e.g., so that the user is prevented from indicating unsupportedvalues of the corresponding entities, such as negative request rates).The user may also specify a bandwidth usage tier in the depictedembodiment using element 2919. Custom preferences for latency, datadurability and/or availability may be provided by clicking on the linkindicated in element 2922, and such preferences may also affect thepricing. An estimate of the billing amount per month, based on thevalues entered by the user, may be provided in element 2925 of web page2901. It is noted that the web page 2901 is just one example of aprogrammatic interface that may be used to allow clients of the loggingservice to select among pricing policy options. A number of otherapproaches, such as the use of pre-defined packages of data stores withdefined performance characteristics (e.g., “small” versus “medium”versus “large” LCSGs) and pricing policies, may be used in otherembodiments. Web pages that take other approaches to pricing, such asbudget-based models in which a user indicates a budget first and is thenguided towards specific data store combinations, workload mixes and soon that can be supported for such a budget may be used in otherembodiments. The factors that are indicated as influencing LCSG pricingmay differ in some embodiments than those indicated in FIG. 29. API,custom pricing GUIs or other programmatic interfaces than web pages maybe used in various embodiments.

FIG. 30 is a flow diagram illustrating aspects of operations that may beperformed to determine billing amounts at a service supportinglog-coordinated storage groups (LCSGs), according to at least someembodiments. As shown in element 3001, the service may determine oridentify a plurality of data stores (such as instances of relationaldatabases, non-relational databases, in-memory databases, distributedcaching environments, storage service object collections, file systems,and the like) that are designated as members of a particularlog-coordinated storage group on behalf of a client. In some embodimentsthe membership information may be obtained at a control plane componentof the service when the data stores are registered (e.g., when the LCSGis set up at the request of a client). In other embodiments a repositoryof LCSG membership information (which may change over time as membersare added or dropped) may be consulted, e.g., at least once everybilling period, to determine the current membership. Reads may bedirected to the data stores via their respective read interfaces, whilewrites may be accepted or rejected by a transaction manager of the LCSGbased at least in part on contents of a write record log.

As shown in element 3004, an indication of a plurality of pricing policyoptions or factors influencing billing amounts for LCSG use may beprovided to the client. In at least some embodiments, the client may usea programmatic interface similar to that shown in FIG. 29 to indicatepotential data store combinations for a given LCSG, and the service maydisplay pricing policy options in response to the client's input. Thepricing policy options may include. A wide variety of factors may play arole in determining pricing in different embodiments, including forexample some combination of the number and types of data stores that aremembers of the LCSG, the mix of operation types (e.g., single-data-storewrites versus multi-data-store writes), resource allocation modes (e.g.,provisioned-throughput versus best-effort), tiered or absoluteperformance levels (e.g., for throughput or latency), bandwidth usage,data durability, availability and so on.

An indication may be received from the client that a particular pricingpolicy, e.g., a policy derived at least in part on input provided by theclient with respect to data store choices, expected workload levels fordifferent operation types such as cross-data-store writes and the like,is to be used for the client's LCSG for at least some time period(element 3007). During the time period, various metrics relevant to thepricing policy may be collected and provided, e.g., to a billing/pricingcontrol plane component of the service. Workload-related metricsincluding the number and rates of various types of client requests (andthe response times or latencies associated with the client requests) maybe collected, as well as resource-related metrics such as the networkbandwidth used by the clients. The control plane component may beresponsible for classifying the workload records (and/or resource usagemetrics) into sub-groups representing different operation categories,such as cross-data-store versus single-data-store writes in someembodiments (element 3010). Based on the collected metrics and thepricing policy selected for or by the client, a billing amount for thetime period may be determined (element 3013) and indicated to the client(element 3016) in the depicted embodiment. In at least one embodiment, aclient may use the service's programmatic interfaces to change billingpolicies for future billing periods.

Descriptors for Read Repeatability Verification

As mentioned earlier, for some types of straightforward read operations,a log-based transaction manager may be able to detect conflicts withsubsequent writes based on the read locations (i.e., informationregarding the addresses from which data was read during a transaction)alone. However, for more complex reads, such purely location-basedconflict detection may not suffice. FIG. 31 illustrates an examplesequence of events at a storage system in which the use ofread-location-based conflict detection for transaction acceptance maylead to data inconsistency, according to at least some embodiments.Timeline 3199 shows a sequence of events E1, E2, E3, E4 and E5 from theperspective of a client of the logging service, with earlier events onthe left and later events on the right. A data store 3110 comprises an“Employees” table with at least three records prior to E1. Each recordhas a respective location (indicated by a label with prefix “L”, such as“Lc”), and includes an employee name field and a salary field. Employee“Andy” has a salary of $X, and employee “Ann” has a salary of $Y in thedepicted example. Event E1 corresponds to a submission by a client of aread request R1 to retrieve the contents of records of employees whosenames begin with “A” (e.g., in SQL-like pseudo-code, a request “Select *from Employees where employee name starts with “A”” may be submitted.)Event E2 comprises a response from the data store, with R1's result setcomprising the records of employees “Andy” and “Ann” Theaddresses/locations Lc and Lk for the two records are also returned tothe client, as well as a logical timestamp LTS1 indicating when the mostrecent committed write (prior to the read) was applied at data store3110.

The client then performs a computation of the average salary (“A_sal”)of employees whose names begin with “A” (event E3), based on R1's resultset. In accordance with the result set received by the client, A_sal isset to the mean of $X and $Y (that is, ($X+$Y)/2). Meanwhile, at sometime corresponding to (LTS1+delta1), a record for a new employee “Art”(with salary $J) is inserted into the Employees table at a location Lnby a write applier. Unaware of the insertion, the client prepares atransaction request TR1 which includes a write of A_sal as computed bythe client. TR1 also indicates the read locations Lc and Lk (e.g., usingrespective hash signatures of the two locations), and the logicaltimestamp LTS1 as a conflict check delimiter. TR1 is examined at alog-based transaction manager (LTM) assigned to data store 3110 at atime corresponding to logical timestamp (LTS1+delta1+delta2) (event E4).As part of conflict detection, the log-based transaction manager checkswhether the read set locations Lc and Lk have been written to sinceLTS1, and does not find any such writes. Accordingly, the requestedtransaction is accepted for commit (event E5) with a commit logicaltimestamp of (LTS1+delta1+delta2) with an inconsistent/incorrect valuefor A_sal. (Given the example sequence of events shown, the value ofA_sal should have been set to ($X+$Y+$J)/3, instead of ($X+$Y)/2, andtherefore may be considered inconsistent or incorrect.) Note that thediscrepancy is not a result of an error made by the LTM, but rather theresult of the fact that for some types of reads, address-basedread-write conflict detection cannot always be used to verify readrepeatability (i.e., to check that the result set of the read would nothave changed were the read to be re-issued).

In order to handle the kinds of problems illustrated in FIG. 31, readdescriptors that are to be included in transaction requests may need toinclude more complex metadata than location indicators such asaddress-based hash signatures. For example, for some types of reads, themetadata may comprise an encoding of at least a portion of the querypredicate used for the reads (e.g., the “where clause” of an SQL-likequery), or even the entire text of the read request. In some cases, afunction (or a pointer to a function) that can be invoked to determinewhether the read's result set has changed may be indicated in themetadata. An expression that can be evaluated to determine whether theresults of the read have changed may be provided as the RRVM in someembodiments. The term “read repeatability verification metadata” (RRVM)may be used herein to refer to information that can be used to determinewhether a corresponding read request would, if, re-submitted, have thesame result set as a previous submission of the read request: that is,whether a given read request represents a “repeatable read” at somepoint after the original submission of the read request.

FIG. 32 illustrates a system environment in which a read descriptorprovided in response to a read request comprises an RRVM component,according to at least some embodiments. As shown, system 3200 includes aheterogeneous storage group 3201 of a storage service, with the storagegroup comprising member data stores 3230A and 3230B. Each data store3230 may present a respective programmatic read interface, such as readinterface 3227A of data store 3230A and read interface 3227B of datastore 3230B. The two data stores may differ not only in the readinterfaces but also in the underlying data models (e.g., one data storemay comprise an instance of a relational database, while the other mayrepresent an instance of a non-relational database). Data stores 3230may have been registered as members of the storage group 3201 at therequest of a particular client in some embodiments, such as the clienton whose behalf the data stores were instantiated at a provider network.Each data store may include a respective plurality of data objects(e.g., records, files, unstructured data objects accessible via webservice interfaces, cache entries or the like, depending on the natureof the data source), such as objects 3210A-3210F of data store 3230A andobjects 3210M-3210Q of data store 3230B. In addition, each data storemay store one or more state transition indicators 3225, such as logicaltimestamps corresponding to various write operations performed at thedata stores. For example, in the case of data store 3230A, if threedifferent writes W1-A, W2-A and W3-A were completed or applied in thatorder, at least one STI 3225A after the write of W3-A is completed maycorrespond to the logical timestamp associated with W3-A. Similarly, atdata store 3230B, at least one STI 3225B after the completion of writesW1-B and W2-B in that order would represent the logical timestampcorresponding to W2-B.

The various member data stores 3230 of the storage group 3201 may eachbe configured to generate read descriptors according to a common readdescriptor format 3298 in the depicted embodiment. In response to a readrequest R1-A received at data store 3230A via read interface 3227A, forexample, a read descriptor 3242A comprising an STI 3246A and RRVM 3244Amay be provided to a client-side component 3235 of the storage service.As described above, the RRVM may be used to determine (or predict withsome high probability), at some point after the original R1-A result set3240A is generated, whether the result set of R1-A would have changed.In at least some embodiments, the client-side component 3235 maycomprise a front-end request handler node of the storage service thatreceives end-user read requests (and/or write requests) form end users3266 and directs corresponding internal requests to the appropriateback-end data stores 3230. In another embodiment, the client-sidecomponent 3235 may comprise a component of a library provided by thestorage service, which may be installed and executed at a client-ownedcomputing device, e.g., either outside the provider network at which theheterogeneous storage group 3201 is implemented, or within the providernetwork. In general, any process or device, located either within aprovider network at which a heterogeneous storage group is implementedor outside the provider network, that is capable of using theprogrammatic interfaces described herein for read requests and/or commitrequests may serve as a client-side component. Similarly, in response toread request R1-B directed to data store 3230B via read interface 3227B,read descriptor 3242B may be provided to the client-side component inaddition to R1-B result set 3240B. Read descriptor 3242B may includeRRVM 3244B, which can be used to verify whether R1-B is a repeatableread, and an STI corresponding to the state of data store 3230B at thetime that R1-B's original result set 3240B is generated. It is notedthat at least in some embodiments, read descriptors 3242 comprisingRRVMs 3244 may be provided in response to read requests independently ofwhether the corresponding read is going to be used for a transactionrequest or not (e.g., whether a write depends on the result set of theread request, or not). Similarly, read descriptors comprising RRVMs maybe provided in at least some embodiments independently of whether thewrites to the data store are performed directly by the client-sidecomponents, or whether writes are coordinated via a log-basedtransaction manager of the kinds described above and/or propagated viawrite appliers of the kinds described above. At least in someembodiments, for simple reads (e.g., “select * from table T1 whererecord_id=RID1”), encodings (e.g., hash signatures) of the address ofthe read object, or of an identifier of the read object, may besufficient for verifying read repeatability. Thus, some RRVMs maycomprise location-based indicators even in embodiments in whichpredicate-based or query-clause-based metadata is generated for testingthe repeatability of more complex reads. In at least one embodiment, afield indicating the type of the RRVM being provided may be included inthe read descriptor—e.g., whether the RRVM is a “single location hashsignature” or a “complex query encoding”.

In at least some embodiments, a data store may store information aboutstate transitions at several different granularities, and more than onestate transition indicator may be included in a read descriptor. FIG. 33illustrates example constituent components of read descriptors,according to at least some embodiments. In the depicted embodiment, anexample data store 3330 comprises a plurality of tables 3310, such astable 3310A and 3310B. Each table includes a number of data records,each with a respective record identifier or RID (which may serve as alocation indicator for the record) 3318 and a respective recordmodification timestamp (RMT) 3320 indicative of the latest update orwrite applied to the record. Thus, for example, table 3310A comprisesrecords with RIDs 3318A, 3318B, and 3318C, while table 3310B comprisesrecords with RIDs 3318K, 3318L and 3318M. Each record may comprise otherdata columns or attributes, which are not shown. The RMTs 3320 mayrepresent logical timestamps (instead of wall-clock-based timestamps) inat least some embodiments, e.g., expressed in terms of output values ofa logical clock accessible to the data store that generatesmonotonically increasing timestamp values. When a record is insertedinto a table 3310, its RMT may be set to the logical timestamp valuecorresponding to the insertion in the depicted embodiment; later, if thesame record is updated, the RMT may be updated to indicate the logicaltimestamp of the update. A logical clock may be responsible forproviding a monotonically increasing sequence of timestamp values (whichmay not correspond to wall-clock time values) in some embodiments. Inone implementation, for each storage group, a single source of logicaltimestamps may be identified (e.g., a clock associated with atransaction manager of the group). In other embodiments, different datastores may use different logical clocks.

In addition to record-level modification time information, table-levelmodification time information may be maintained in the depictedembodiment as well, in the form of table modification timestamps (TMTs)such as TMT 3316A for table 3310A and TMT 3316B for table 3310B. The TMTof a table 3310 may indicate the most recent RMT among the RMTs ofrecords of that table in the depicted embodiment. Thus, for table 3310,if at a given point in time the record with RID 3318C is the mostrecently-written-to record within the table, TMT 3316A may also containthe same logical timestamp value as RMT 3320C. Similarly, at an evenhigher granularity, a data store modification timestamp (DMT) 3308 maybe set to the most recent TMT value among the TMTs of the tables,indicative of the most recent change among any of the records stored atthe data store 3330.

In the embodiment shown in FIG. 33, a read descriptor for a readdirected to a given record within data store 3310 may indicate themodification logical timestamps for all three levels of thehierarchy—the record level (e.g., indicating the last time at which therecord being read was modified), the table level, and the data storelevel. As shown, in response to a read request R1 whose result setcomprises record 3318B of table 3310A, the read descriptor RD1 generatedmay include RMT 3320B, TMT 3316A, and DMT 3308 (in addition to readrepeatability verification metadata (RRVM) 3340A). Similarly, inresponse to read request R2 whose result set comprises record 3318M oftable 3310B, the read descriptor RD2 may include RMT 3320M, TMT 3316B,DMT 3308, and different RRVM 3340B. If a result set of a read comprisesseveral different records, the minimum of the RMTs of those records maybe included in some implementations, while the RMTs of all the recordsmay be included in the read descriptor in other implementations.Similarly, if the result of a given read request comprises records frommore than one table, the minimum TMT among the tables' TMTs may beindicated in the read descriptor in some embodiments, while a vectorcomprising all the tables' TMTs may be included in other embodiments.Other hierarchies of state transition records may be used in differentimplementations, and for different types of data stores. For example, inan embodiment in which a data store table is divided into partitions,partition modification timestamps may be included in the readdescriptors (e.g., in addition to or instead of TMTs). For data storesthat implement file systems, logical timestamps for writes to files,directories and file systems may be used as the hierarchy of statetransition indicators in some embodiments. Inclusion of a hierarchy ofstate transition indicators (instead of just a single value such as theDMT) in read descriptors may enable log-based transaction managers tomake concurrency control decisions at different levels ofconservativeness in some embodiments. For example, in one conservativeapproach, the transaction manager may identify any writes that have beendirected to any of the records of the data store since the DMT asconflicting writes, while in a less conservative approach, only writesthat have been directed to the specific record(s) read since its RMT maybe considered conflicts.

As indicated in FIG. 32, read descriptors may be provided by data storesof a storage group to client-side components of the system in at leastsome embodiments. The read descriptors may be incorporated withintransaction commit requests generated at the client-side components insome such embodiments, and examined by transaction managers forconcurrency control purposes. For a number of reasons, while the readdescriptors may have to be decipherable by transaction managers, theoperator of a logging service or the provider network may not want theinternal details of the read descriptors to be visible to end users thatsubmit the read and write requests in at least some embodiments. Forexample, the service operator may wish to retain the ability to changethe format or contents of read descriptors, which may be harder to do ifend users have become used to expecting end-user-readable readdescriptors of a fixed size. Accordingly, the contents of readdescriptors may be subjected to one or more transformations before theyare transmitted to the client-side components in some embodiments. FIG.34 illustrates example transformations that may be applied to readdescriptors before the read descriptors are provided to client-sidecomponents of a storage system, according to at least some embodiments.Respective modification logical timestamps for three levels of a storagehierarchy (data store, table and record) are included in the readdescriptors generated in the depicted embodiment. As shown a readdescriptor 3401 in unmodified or pre-transformation state may compriseN1+N2+N3+N4 bytes, with N1 bytes used for an original DMT 3408, N2 bytesfor the original TMT 3416, N3 bytes for the original RMT 3420, and N4bytes for the RRVM 3440.

In a first transformation, a number (N5) of bytes may be added to theread descriptor as “padding” in the depicted embodiment. Differentnumbers of bytes may be added to different read descriptors generated atthe same data store in some embodiments, e.g., using a random numbergenerator to select the number of padding bytes from within someselected range of padding sizes. In some embodiments, the padding bytesmay be populated with randomly-selected data as well. Suchrandomly-generated padding elements may help ensure that end users donot assume that all read descriptors will have the same size.

In addition to the padding transformation, the read descriptor may alsoor instead be encoded or obfuscated in some embodiments, so that itselements are no longer interpretable or understandable without decoding.Thus, for example, padded read descriptor 3451 may be encrypted orencoded into obfuscated read descriptor 3458 before transmission to theclient-side component. Server-side components of the storage service(such as the transaction manager at which the read descriptor may haveto be decoded) may have the necessary metadata (e.g., decryptioncredentials, or an indication of the function or method to be used fordecoding the read descriptor) in the depicted embodiment, butinformation required to undo the obfuscation may not be made accessibleto end users. Different sequences of the two transformations (paddingand obfuscation) may be performed in various embodiments—e.g., theoriginal versions of the read descriptor elements may be encoded firstin some embodiments, before the padding bytes are added. In someembodiments, only padding or only obfuscation may be used. In at leastsome embodiments, other transformations may be applied as well beforethe read descriptors are transmitted to client-side components—e.g., thedescriptors may be compressed.

Stateless Data-Store-Independent Transactions

FIG. 35 illustrates an example sequence of operations leading to asubmission of a candidate transaction commit request from a client-sidecomponent of a storage system, according to at least some embodiments.The client-side component may, for example, comprise a process runningat a front-end request handler of a storage service, or a component of astorage-service-provider library installable at a client-owned computingdevice. A BEGIN_TRANSACTION request may be received at the client-sidecomponent, e.g., from an end user, at time t1 on client-side componenttimeline 3599. The client-side component may allocate or reserve memorybuffers 3535 for preparing a candidate transaction request in responseto the BEGIN_TRANSACTION request in some embodiments. In otherembodiments, memory buffers 3535 may be allocated dynamically asdifferent reads and/or writes of the transaction are completed.

At time t2 on timeline 3599, a read request R1 may be directed from theclient-side component (e.g., in response to an end-user read requestreceived at a service front-end request handler or library component) toa data store DS1 of a heterogeneous storage group 3575 via a statelessprotocol. The heterogeneous storage group 3575 may include member datastores DS1, DS2, DS3 and DS4 in the depicted embodiment, each of whichmay have been registered as a member of the storage group whose writeoperations are to be managed via a log-based transaction manager (LTM).The members of the storage group 3575 may also be required to generateand transmit read descriptors (e.g., descriptors comprising statetransition indicators and RRVMs of the kinds described above) inresponse to read requests. At least some members of the storage groupmay implement different data models in some embodiments (e.g.,relational versus non-relational, structured versus unstructuredrecords), with corresponding read interfaces and record/object storageformats. As mentioned earlier, a number of different categories of datastores may be included in a storage group, including for exampleinstances of relational databases, non-relational databases, in-memorydatabases, distributed caches, collections of storage objects accessiblevia web-service interfaces implemented by a provider network service, aqueueing service implemented at a provider network, or a notificationservice implemented at a provider network. The protocol used for theread request R1 may be stateless in that, after the result set 3510A andread descriptor 3512A corresponding to R1 are transmitted to theclient-side component, DS1 may not retain any session metadatapertaining to the client-side component in the depicted embodiment. Anyof various stateless application-layer protocols may be used for theread request and response in different embodiments, such as any ofvarious HTTP (HyperText Transfer Protocol) variants in accordance with aREST (representational state transfer) architecture. The result set3510A and the read descriptor 3512A may be stored in the memory buffers3535.

At time t3 of timeline 3599, a second read request R2 within the scopeof the transaction may be submitted to a second data store DS2 ofstorage group 3575 via stateless protocol, e.g., in response to anotherread request of the end user. Once again, after providing the result set3510B and the read descriptor 3512B to the client-side component, thedata store DS2 may not retain any session state metadata pertaining toR2 or the client-side component. In the depicted embodiment, none of themember data stores of the storage group 3575 may be aware of the factthat a transaction has been begun at the client-side component; to thedata stores, each read request may appear simply as a standalone requestthat is unrelated to any other read or write.

At time t4, a write W1 whose payload 3520A depends on R2's result setand is ultimately to be applied to data store DS3 (if the candidatetransaction being prepared is eventually committed) may be performedlocally, e.g., to a portion of memory within the client-side buffers3535 in the depicted embodiment. A write descriptor 3522A for W1,indicative of the target address to which W1 is directed, may also becreated in the buffers. For example, a hash signature of the targetaddress may be used as the write descriptor 3522A in someimplementations. At time t5, write W2, whose payload 3520B is dependenton R1's result set and is directed towards DS4 may similarly beperformed in local memory of the client-side component. A second writedescriptor 3522B for W2 may also be prepared in the client-sidecomponent's memory buffer 3535 in the depicted embodiment.

At time t6, a COMMIT_TRANSACTION request may be received from the enduser. Accordingly, the read descriptors 3512A and 3512B, the writedescriptors 3522A and 3522B, and the write payloads 3520A and 3520B mayall be packaged into a candidate transaction commit request 3524 forsubmission to the LTM of the storage group 3575. The conflict detector3566 of the LTM may determine, based on analysis of the read descriptorsand contents of a selected subset of the LTM's commit record log (wherethe subset is selected based at least in part on the read descriptors),whether to accept or reject the candidate transaction. If a read-writeconflict is detected (e.g., as a result of a determination using an RRVMincluded in one of the read descriptors) that either R1 or R2 is notrepeatable because a subsequent write has changed the result set thatwould be returned if the read request were re-submitted, the candidatetransaction may be rejected. In such a scenario, the client-sidecomponent may re-try the reads R1 and R2 in the depicted embodiment,obtaining new results sets and read descriptors, and generate a newcandidate transaction commit request for submission to the LTM. Suchretries may be attempted some threshold number of times before one ofthe attempts succeeds, or before the end-user on whose behalf thetransaction is being requested is informed that the transaction failed.

If the conflict detector 3566 accepts the commit request 3524, the writedescriptors and payloads of W1 and W2 may be stored in the LTM's log inthe depicted embodiment. In at least some embodiments, the writedescriptors may be considered the logical “duals” of the readdescriptors included in the commit requests, in that in order to detectconflicts, writes indicated by previously-stored write descriptors mayhave to be checked for potential or actual overlaps with reads indicatedby the read descriptors. Thus, at a high level, the manner in whichwrites are indicated in the write descriptors in a given implementationmay have to be logically compatible with the manner in which reads areindicated in the read descriptors. Write appliers 3568 of the LTM may,either synchronously or asynchronously with respect to the acceptdecision, apply the writes W1 and W2 to their target data stores DS3 andDS4. In some embodiments, the write appliers may also utilize statelessprotocols, and the targeted data stores DS3 and DS4 may not have tostore any session-related metadata pertaining to the write appliers orto the write requests issued by the write appliers.

Thus, in the embodiment shown in FIG. 35, multiple writes (such as W1and W2) may be committed as part of an atomic transaction prepared at aclient-side component, without any transaction-related metadata beinggenerated or stored at the data stores involved. Such client-sidemulti-write transactions may be implemented in some embodiments eventhough the underlying data stores may not natively support multi-writetransactions, and/or even though the underlying data stores may onlysupport stateless read and write operations. That is, transactionalatomicity and consistency may be provided to the users of aheterogeneous storage group even though member data stores do not retainsession information (or transaction state information) between the timeof occurrence of a given read and the time of occurrence of a write thatdepends on the results of the given read.

As described earlier, a log-based transaction manager may store writedescriptors (such as 3522A and 3522B) corresponding to committed writesin a persistent change log (such as a log implemented using thereplication DAGs described above). In some embodiments, the contents ofread descriptors may also be saved by a transaction manager, even thoughthe read descriptors of a committed transaction may not be required formaking future commit decisions. FIG. 36 illustrates an exampletransaction manager that stores write descriptors and read descriptorsin respective logs, according to at least some embodiments. As shown,log-based transaction manager 3602 uses two separate persistent logs: awrite descriptor log 3610 and a read descriptor log 3620. In otherembodiments, both types of descriptors may be stored in a sharedpersistent log. The contents of read descriptor log 3610 may be used tocheck for read-write conflicts as part of the optimistic concurrencycontrol approaches described earlier, and/or for logical constraintmanagement as also described earlier. Read descriptor log 3620 may beused, for example, for workload analysis, e.g., to determine thedistribution of reads across different portions of the heterogeneousstorage group. In some embodiments, the read descriptors of bothcommitted and rejected transactions may be retained for workloadanalysis purposes. The read descriptors of rejected transactions mayalso be analyzed to identify the causes of transaction rejections—e.g.,to determine whether any actions should be taken (such as partitioning aparticular data object that is read frequently enough and updatedfrequently enough to cause a lot of transaction rejections) to reducethe frequency of transaction rejection.

FIG. 37 is a flow diagram illustrating aspects of operations that may beperformed at a storage system in which read descriptors are provided inresponse to read requests, according to at least some embodiments. Asshown in element 3701, a heterogeneous storage group HSG1 comprising aplurality of data stores may be established. Different data modelsand/or read interfaces may be supported by the member data stores of thegroup—e.g., the group may comprise one or more instances of a relationaldatabase, a non-relational database, an in-memory database, adistributed cache instance, a file store or file system, a storageservice that comprises unstructured data objects accessible via a webservice interface, and so on. Clients of the service implementing HSG1may register (add) data stores to the group or remove data stores fromthe group programmatically. In at least some embodiments, all the memberdata stores of the group HSG1 may be required to respond to readrequests with (in addition to the read result sets) read descriptors inaccordance with a common read descriptor format indicated by theservice.

A particular read request R1, directed to a data store DS1 of HSG1 maybe received (element 3704). R1 may include an indication of a filteringcriterion to be used to determine its result set. The nature of thefiltering criterion may differ, depending on the type of data storetargeted. For example, if R1 is a database that supports SQL (StructuredQuery Language) or SQL-like interfaces, the filtering criterion may beexpressed as an SQL select clause. If DS1 is a storage service thatpresents a web service interface, the filtering criterion may beexpressed as one or more URLs (Universal Resource Locators). Forkey-value data stores, the filtering criterion may comprise a set ofunique keys which in turn correspond to specific recordlocations/addresses within the data store. The result set of the readrequest may be identified, together with one or more state transitionindicators (STIs) of the data store DS1 that represent apreviously-committed state of DS1 (element 3707). The STIs may compriselogical timestamps corresponding to the application of committed writesto the data stores in some embodiments, such that the results of thecommitted writes were visible at the time that the result set isgenerated. In one implementation, for example, the STIs may include oneor more of: a data-store-level modification logical timestamp, atable-level modification logical timestamp, or a record-levelmodification logical timestamp (e.g., the DMTs, TMTs and RMTsillustrated in FIG. 33). In some embodiments, wall-clock-basedtimestamps may be used instead of or in addition to logical timestamps.

A read descriptor RD1 corresponding to R1 may be generated (element3710). The read descriptor may include, for example, the STI(s) and atleast some read repeatability verification metadata (RRVM). The RRVM maybe used, for example, to determine whether R1 is a repeatable read,i.e., whether, at some point after the result set is obtained the firsttime, R1's result set would remain unchanged if R1 were re-issued. Theformat and content of the RRVM may differ in different embodiments,e.g., based on the types of reads for which repeatability is to bedetermined, the nature of the data store involved, and so on. In someembodiments, for example, the RRVM may include an encoding of a locationfrom which an object of the R1 result set is obtained, such as a hashsignature of at least one such location. For reads with more complexfiltering/selection criteria, such as range queries or queries similarto the read discussed in the context of FIG. 31, an encoding of thequery predicate or select clause may be included in the RRVM. In someembodiments, an expression that can be evaluated (or a function that canbe executed) to determine whether the results of R1 have changed may beindicated in the RRVM. In one implementation, the entire read request R1may be included in the RRVM, e.g., in an encoded or compressed format.In some embodiments in which several different types of RRVM may begenerated (e.g., address-based signatures versus query predicateencodings versus functions), the type of RRVM may be indicated by afield within the read descriptor RD1. RD1 may be transmitted to aclient-side component of HSG1 (e.g., a front-end request handler node ofthe service at which HSG1 is implemented, or a library component of theservice). RD1 may be used at the client-side component for constructinga transaction commit request in some embodiments, or for other purposessuch as workload analysis.

FIG. 38 is a flow diagram illustrating aspects of operations that may beperformed at a storage service in which candidate transaction commitrequests are generated at a client-side component, according to at leastsome embodiments. The client-side component may comprise, for example,one or more processes running at a front-end request handler node of thestorage service, or within a library provided by the storage service toa customer. As shown in element 3801, an indication that a candidatetransaction is to be prepared may be received at a client-side componentof a heterogeneous storage group HSG1 from an end-user, such as aBEGIN_TRANSACTION request received via an application programminginterface (API) of the service. In some implementations, the set ofoperations performed at the client-side component between aBEGIN_TRANSACTION request and a COMMIT_TRANSACTION request (or anEND_TRANSACTION request) may be considered to be within the scope of thetransaction, e.g., in the sense that the repeatability of the readsissued within that interval may have to be verified before the writes ofthe transaction are committed.

One or more read requests may be directed to the data stores of thestorage group HSG1 within the scope of the transaction by theclient-side component, e.g., in response to read API calls made by theend-user. At least some of the reads may be performed using a statelessprotocol in the depicted embodiment—that is, the data store to which aread is directed may not be required to maintain client sessioninformation, or retain any other persistent metadata pertaining to theread request. The data store may have no information indicating that theresults of the read are going to be used for a write operation ortransaction, for example. Corresponding to each such read request, aresult set and a read descriptor may be provided by the targeted datastore (element 3804). A given read descriptor may include one or morestate transition indicators (STIs) indicative of a committed state ofthe data store (or a committed state of a subset of the data store, suchas a table or a record in the case of a database instance) as of thetime the result set is obtained. In addition, a read descriptor may alsocontain at least one element of read repeatability verification metadata(RRVM)—e.g., information such as an encoding of a read query orpredicate, a function, or a hash signature representing a read targetlocation, which can be used to check whether the results of the readwould have changed if the read were re-submitted. The read result setsand read descriptors may be stored in memory buffers accessible by theclient-side component (element 3807), e.g., in local memory at thefront-end request handler node or at a client-owned computing device.

One or more writes whose write payloads may be dependent upon at leastone of the read result sets may be performed using local memory—e.g.,the write payloads may be stored in buffers writable by the client-sidecomponent. In at least one embodiment, the target location at a datastore of HSG1 that is eventually to be written to as a result of a writewithin the transaction's scope may also be dependent on a read resultset. A write descriptor (e.g., a hash signature based on the target HSG1location of a write) may also be stored for at least some of the writesin client-side memory buffers in some embodiments (element 3810). It isnoted that in some embodiments, write descriptors may not berequired—e.g., a write payload may include an indication of a writelocation, and the location indication may suffice for read-writeconflict detection. After all the reads and writes of the transactionare performed locally, an indication that the transaction's localoperations have been completed (such as a COMMIT_TRANSACTION orEND_TRANSACTION request) may be received at the client-side component(element 3813).

A commit request for the candidate transaction may be generated at theclient-side component, comprising the read descriptors, write payloadsand write descriptors in the depicted embodiment (element 3816). It isnoted that in some embodiments, one or more writes included within thescope of a transaction may not necessarily depend on results of a readindicated in the transaction. In some embodiments, in which for examplelogical constraints of the kind described earlier (e.g., de-duplicationconstraints or commit sequencing constraints) are to be checked beforethe candidate transaction is accepted for commit, additional datasignatures may be generated for the logical constraints and incorporatedinto the commit request. The commit request may be transmitted to atransaction manager responsible for making commit decisions for HSG1(element 3819), such as a log-based transaction manager configured touse an optimistic concurrency control mechanism of the kind describedabove. A decision as to whether to commit or reject the candidatetransaction may be made at the transaction manager (element 3822), e.g.,using the read descriptors and a selected subset of a log to identifyread-write conflicts as described earlier. If a decision to accept thecandidate transaction is made (e.g., if read-write conflicts are notdetected in accordance with the concurrency control protocol beingused), a new commit record may be added to the transaction manager'slog. In at least some embodiments, the log may be implemented using areplication directed acyclic graph (DAG) as described earlier.

It is noted that in various embodiments, operations other than thoseillustrated in the flow diagram of FIGS. 6, 7, 8, 9, 10, 12, 13, 14, 19,20, 25, 30, 37 and 38 may be used to implement at least some of thetechniques described above. Some of the operations shown in the flowchart may not be implemented in some embodiments, may be implemented ina different order, or may be performed in parallel rather thansequentially.

Use Cases

The techniques described above, of managing application state changesusing replication DAGs, including log-based transaction management usingread descriptors and client-side transaction preparation, may be usefulin a variety of embodiments. As more and more organizations migratetheir computing to provider network environments, a larger variety ofdistributed storage applications with respective consistency semanticsand respective interfaces has been developed. Some large applicationsmay span multiple data store instances, and the replication DAGs andlog-based transaction management techniques may represent a unified,flexible, scalable, and highly-available approach to distributed storageapplication management. The ability of the replication DAG nodes to makeprogress on application state transitions even though the respectiveviews of the DAG configuration may at least temporarily diverge mayreduce or eliminate at least some of the “stop-the-world” pauses inhandling application requests that may arise if less dynamic replicationtechniques are used. Log-based transaction management may not only allowcross-data-store transactions (as well as multi-item transactions fordata stores that may not support atomic multi-write transactions), butmay also facilitate features such as automated query responsegeneration, snapshot generation, and the like. Entirely new ways ofperforming data analysis across multiple data stores may be enabledusing the logging service's own read interfaces. Pricing policies thatclarify the costs of such new types of cross-data-store operations maybe implemented, enabling users to make informed budgeting decisions fortheir data transformation requirements.

In some provider network environments, log-based transaction managementvia replication DAGs may be used to store control-plane configurationinformation of another network-accessible service implemented at theprovider network, such as a virtualized computing service, a storageservice, or a database service. In such scenarios, the transactionsmanaged using the log may represent changes to the configurations ofvarious resources of the network-accessible service (such as computeinstances or virtualization hosts in the case of a virtual computingservice).

Illustrative Computer System

In at least some embodiments, a server that implements a portion or allof one or more of the technologies described herein, including thetechniques to implement the various components of a replication DAG, alogging service for transaction management, or a heterogeneous storagesystem (including client-side components such as front-end requesthandlers) may include a general-purpose computer system that includes oris configured to access one or more computer-accessible media. FIG. 39illustrates such a general-purpose computing device 9000. In theillustrated embodiment, computing device 9000 includes one or moreprocessors 9010 coupled to a system memory 9020 (which may comprise bothnon-volatile and volatile memory modules) via an input/output (I/O)interface 9030. Computing device 9000 further includes a networkinterface 9040 coupled to I/O interface 9030.

In various embodiments, computing device 9000 may be a uniprocessorsystem including one processor 9010, or a multiprocessor systemincluding several processors 9010 (e.g., two, four, eight, or anothersuitable number). Processors 9010 may be any suitable processors capableof executing instructions. For example, in various embodiments,processors 9010 may be general-purpose or embedded processorsimplementing any of a variety of instruction set architectures (ISAs),such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitableISA. In multiprocessor systems, each of processors 9010 may commonly,but not necessarily, implement the same ISA. In some implementations,graphics processing units (GPUs) may be used instead of, or in additionto, conventional processors.

System memory 9020 may be configured to store instructions and dataaccessible by processor(s) 9010. In at least some embodiments, thesystem memory 9020 may comprise both volatile and non-volatile portions;in other embodiments, only volatile memory may be used. In variousembodiments, the volatile portion of system memory 9020 may beimplemented using any suitable memory technology, such as static randomaccess memory (SRAM), synchronous dynamic RAM or any other type ofmemory. For the non-volatile portion of system memory (which maycomprise one or more NVDIMMs, for example), in some embodimentsflash-based memory devices, including NAND-flash devices, may be used.In at least some embodiments, the non-volatile portion of the systemmemory may include a power source, such as a supercapacitor or otherpower storage device (e.g., a battery). In various embodiments,memristor based resistive random access memory (ReRAM),three-dimensional NAND technologies, Ferroelectric RAM, magnetoresistiveRAM (MRAM), or any of various types of phase change memory (PCM) may beused at least for the non-volatile portion of system memory. In theillustrated embodiment, program instructions and data implementing oneor more desired functions, such as those methods, techniques, and datadescribed above, are shown stored within system memory 9020 as code 9025and data 9026.

In one embodiment, I/O interface 9030 may be configured to coordinateI/O traffic between processor 9010, system memory 9020, and anyperipheral devices in the device, including network interface 9040 orother peripheral interfaces such as various types of persistent and/orvolatile storage devices. In some embodiments, I/O interface 9030 mayperform any necessary protocol, timing or other data transformations toconvert data signals from one component (e.g., system memory 9020) intoa format suitable for use by another component (e.g., processor 9010).In some embodiments, I/O interface 9030 may include support for devicesattached through various types of peripheral buses, such as a variant ofthe Peripheral Component Interconnect (PCI) bus standard or theUniversal Serial Bus (USB) standard, for example. In some embodiments,the function of I/O interface 9030 may be split into two or moreseparate components, such as a north bridge and a south bridge, forexample. Also, in some embodiments some or all of the functionality ofI/O interface 9030, such as an interface to system memory 9020, may beincorporated directly into processor 9010.

Network interface 9040 may be configured to allow data to be exchangedbetween computing device 9000 and other devices 9060 attached to anetwork or networks 9050, such as other computer systems or devices asillustrated in FIG. 1 through FIG. 38, for example. In variousembodiments, network interface 9040 may support communication via anysuitable wired or wireless general data networks, such as types ofEthernet network, for example. Additionally, network interface 9040 maysupport communication via telecommunications/telephony networks such asanalog voice networks or digital fiber communications networks, viastorage area networks such as Fibre Channel SANs, or via any othersuitable type of network and/or protocol.

In some embodiments, system memory 9020 may be one embodiment of acomputer-accessible medium configured to store program instructions anddata as described above for FIG. 1 through FIG. 38 for implementingembodiments of the corresponding methods and apparatus. However, inother embodiments, program instructions and/or data may be received,sent or stored upon different types of computer-accessible media.Generally speaking, a computer-accessible medium may includenon-transitory storage media or memory media such as magnetic or opticalmedia, e.g., disk or DVD/CD coupled to computing device 9000 via I/Ointerface 9030. A non-transitory computer-accessible storage medium mayalso include any volatile or non-volatile media such as RAM (e.g. SDRAM,DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in someembodiments of computing device 9000 as system memory 9020 or anothertype of memory. Further, a computer-accessible medium may includetransmission media or signals such as electrical, electromagnetic, ordigital signals, conveyed via a communication medium such as a networkand/or a wireless link, such as may be implemented via network interface9040. Portions or all of multiple computing devices such as thatillustrated in FIG. 39 may be used to implement the describedfunctionality in various embodiments; for example, software componentsrunning on a variety of different devices and servers may collaborate toprovide the functionality. In some embodiments, portions of thedescribed functionality may be implemented using storage devices,network devices, or special-purpose computer systems, in addition to orinstead of being implemented using general-purpose computer systems. Theterm “computing device”, as used herein, refers to at least all thesetypes of devices, and is not limited to these types of devices.

CONCLUSION

Various embodiments may further include receiving, sending or storinginstructions and/or data implemented in accordance with the foregoingdescription upon a computer-accessible medium. Generally speaking, acomputer-accessible medium may include storage media or memory mediasuch as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile ornon-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.),ROM, etc., as well as transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as network and/or a wireless link.

The various methods as illustrated in the Figures and described hereinrepresent exemplary embodiments of methods. The methods may beimplemented in software, hardware, or a combination thereof. The orderof method may be changed, and various elements may be added, reordered,combined, omitted, modified, etc.

Various modifications and changes may be made as would be obvious to aperson skilled in the art having the benefit of this disclosure. It isintended to embrace all such modifications and changes and, accordingly,the above description to be regarded in an illustrative rather than arestrictive sense.

What is claimed is:
 1. A system, comprising: one or more computingdevices configured to: receive, at a client-side component of aheterogeneous storage group comprising a plurality of data storesincluding a first data store and a second data store, respective readdescriptors corresponding to one or more reads, including a first readdescriptor corresponding to a first read directed to the first datastore, wherein the first read descriptor comprises an indication of astate transition that has been applied at the first data store, andwherein, in accordance with a stateless protocol, the first data storedoes not maintain session metadata pertaining to the client-sidecomponent after the first read descriptor is provided to the client-sidecomponent; store, in one or more buffers accessible to the client-sidecomponent, respective write descriptors of one or more writes, includinga first write descriptor of a first write directed to a particular datastore of the heterogeneous storage group, wherein a payload of the firstwrite is based at least in part on a result of the first read, andwherein the first write descriptor indicates an object to be modified atthe particular data store; generate, at the client-side component, acommit request for a candidate transaction comprising the one or morewrites, wherein the commit request comprises at least the first readdescriptor and the first write descriptor; transmit, from theclient-side component to a transaction manager, the commit request;determine, at the transaction manager, that the candidate transaction isaccepted for commit based at least in part on an analysis of the firstread descriptor in accordance with a concurrency control protocol; andinitiate a modification of the object indicated in the first writedescriptor.
 2. The system as recited in claim 1, wherein the client-sidecomponent comprises a process executing at a request handler node of astorage service implemented at a provider network.
 3. The system asrecited in claim 1, wherein the first read descriptor comprises readrepeatability verification metadata for at least the first read.
 4. Thesystem as recited in claim 1, wherein the commit request includes asecond read descriptor corresponding to a second read directed to thesecond data store, wherein a payload of at least one write of the one ormore writes is based at least in part on a result of the second read. 5.The system as recited in claim 1, wherein the one or more writescomprise a second write directed to a different data store than theparticular data store.
 6. A method, comprising: performing, by one ormore computing devices: receiving, at a client-side component of astorage group comprising one or more data stores including a first datastore, respective read descriptors corresponding to one or more reads,including a first read descriptor corresponding to a first read directedto the first data store, wherein the first read descriptor comprises anindication of a state transition that has been applied at the first datastore; generating, at the client-side component, respective writedescriptors of one or more writes, including a first write descriptor ofa first write directed to a particular data store of the one or moredata stores, wherein a payload of the first write is based at least inpart on a result of the first read, and wherein the first writedescriptor indicates an object to be modified at the particular datastore; transmitting, from the client-side component to a transactionmanager, a commit request for a candidate transaction comprising one ormore writes including the first write, wherein the commit requestcomprises at least the first read descriptor and the first writedescriptor; determining, at the transaction manager, that the candidatetransaction is to be accepted for commit based at least in part on ananalysis of the first read descriptor.
 7. The method as recited in claim6, wherein in accordance with a stateless protocol, the first data storedoes not maintain session metadata pertaining to the first read afterthe first read descriptor is provided to the client-side component. 8.The method as recited in claim 6, further comprising performing, by theone or more computing devices: storing, in a durable log of thetransaction manager, a transaction record indicating that the candidatetransaction has been accepted for commit; wherein said determining thatthe candidate transaction is to be accepted for commit is based at leastin part on an analysis of one or more other transaction records storedin the durable log.
 9. The method as recited in claim 8, wherein thedurable log is implemented using a plurality of nodes of a replicationgraph.
 10. The method as recited in claim 6, wherein said determiningthat the candidate transaction is to be accepted for commit comprisesverifying that a result set of the first read has not been modifiedsince the read descriptor was generated.
 11. The method as recited inclaim 6, wherein the indication of the particular state transitioncomprises a logical timestamp.
 12. The method as recited in claim 6,wherein the first read descriptor comprises read repeatabilityverification metadata for at least the first read.
 13. The method asrecited in claim 6, wherein the one or more data stores comprise asecond data store, wherein the first data store implements a first datamodel and the second data store implements a different data model,wherein the commit request includes a second read descriptorcorresponding to a second read directed to the second data store,wherein a payload of at least one write of the one or more writes isbased at least in part on a result of the second read.
 14. The method asrecited in claim 12, wherein the first data store comprises one of: anon-relational database system, a relational database system, a storageservice that implements a web services interface allowing access tounstructured data objects, an in-memory database, an instance of adistributed cache, a component of a queueing service, or a component ofa notification service.
 15. The method as recited in claim 6, whereinthe first data store does not support atomicity for a transaction thatincludes more than one write.
 16. A non-transitory computer-accessiblestorage medium storing program instructions that when executed on one ormore processors: receive, at a client-side component of a storage groupcomprising one or more data stores including a first data store,respective read descriptors corresponding to one or more reads,including a first read descriptor corresponding to a first read directedto the first data store, wherein the first read descriptor comprises anindication of a state transition that has been applied at the first datastore; generate, at the client-side component, respective writedescriptors of one or more writes, including a first write descriptor ofa first write directed to a particular data store of the one or moredata stores, wherein a payload of the first write is based at least inpart on a result of the first read, and wherein the first writedescriptor indicates an object to be modified at the particular datastore; and transmit, from the client-side component to a transactionmanager, a commit request for a candidate transaction comprising one ormore writes including the first write, wherein the commit requestcomprises at least the first read descriptor and the first writedescriptor.
 17. The non-transitory computer-accessible storage medium asrecited in claim 16, wherein in accordance with a stateless protocol,the first data store does not maintain session metadata pertaining tothe first read.
 18. The non-transitory computer-accessible storagemedium as recited in claim 16, wherein the first read descriptorcomprises read repeatability verification metadata for at least thefirst read.
 19. The non-transitory computer-accessible storage medium asrecited in claim 16, wherein the one or more data stores comprises asecond data store, wherein the first data store implements a first datamodel and the second data store implements a different data model,wherein the commit request includes a second read descriptorcorresponding to a second read directed to the second data store,wherein a payload of at least one write of the one or more writes isbased at least in part on a result of the second read.
 20. Thenon-transitory computer-accessible storage medium as recited in claim16, wherein the first data store does not support atomicity for atransaction that includes more than one write.